Libguestfs - Nov 2014 - Re: virt-v2v: Died at /usr/bin/virt-p2v-server line 411

Le 19/11/2014 15:03, Richard W.M. Jones a écrit :
> On Wed, Nov 19, 2014 at 02:41:49PM +0100, Nicolas Ecarnot wrote:
>> When trying to p2v an Oracle Linux 7.0 VM, it ran very verbosely
>> then failed saying it was not a kind of OS it knows how to convert.
>
> We could probably support OEL with a bit of effort, but it's not
> supported now.  The virt-v2v manual (which you should read, as well as
> the virt-p2v manual) provides a list of all OSes which are supported.
Richard,

Don't worry, I can ensure you that I'm reading and reading and reading 
again.
BTW, these docs are very well done. This is comfortable.

Concerning OL7, this is not a serious issue, this was just a test.
>> When trying to p2v a old windows XP VM, it ran the same long way
>> then failed telling that no root device was found in this operating
>> system image.
>
> Windows XP should work.  If it doesn't work you have to enable
> debugging (this is now enabled by default in all new virt-p2v
> versions), and then provide the full debug logs.  See the instructions
> for where these are located on the conversion server.
In the mean time, I googled around and found that though I copied the 
right virtio-win hierarchy into the conversion server, I also had to 
install the missing libguestfs-winsupport.
Another run of p2v of the previous windows XP succeed!
I did not try to import it into RHEV, but I can see it appearing in the 
export domain list. So I guess the hardest part is done.
>> As I read in detail the very long log, I saw different things
>> failing, and amongst them, the issue telling that the 36:36
>> permissions on the NFS export share will prevent the import into
>> RHEV. I don't know if it is an issue at this point. Anyway, I
don't
>> see any image coming into this nfs subtree at present.
>
> When using '-o rhev', permissions should be set correctly for you
> automatically.  Instead of summarising and interpreting what the debug
> logs say (which is not useful), provide the debug logs.
I knew you would say that, but I'm still searching for a way to 
copy-paste from a Dell iDrac environnment...

Well, now, I had the opportunity to run the real P2V on the 2003 server, 
and it is failing.
But it appears that the partition seems more complex than what I'm used 
to see ("two system (dell?) or windows system partitions").
I choose the third one, that is the one containing the system (C:) and 
marked as bootable.

It is failing very quickly, with the following error :
--------------------
Creating an overlay to protect the source blahblah
qemu-img create -q -f qcow2 -b 'nbd:localhost:55756' -o 
'compat=1.1,backing_fmt=raw' /var/tmp/v2vblahblah.qcow2
nbd.c:nbd_receive_negociate():L501: read failed
qemu-img: /var/tmp/v2vvovblahbla.qcow2: could not open 
'nbd:localhost:55756': could not open image: invalid argument: invalid 
argument

then other blahblahblah before closing.

I'll try another run by selecting every partition.



-- 
Nicolas Ecarnot

On Wed, Nov 19, 2014 at 03:50:24PM +0100, Nicolas Ecarnot
wrote:
> Well, now, I had the opportunity to run the real P2V on the 2003
> server, and it is failing.
> But it appears that the partition seems more complex than what I'm
> used to see ("two system (dell?) or windows system partitions").
> I choose the third one, that is the one containing the system (C:)
> and marked as bootable.
> 
> It is failing very quickly, with the following error :
> --------------------
> Creating an overlay to protect the source blahblah
> qemu-img create -q -f qcow2 -b 'nbd:localhost:55756' -o
> 'compat=1.1,backing_fmt=raw' /var/tmp/v2vblahblah.qcow2
> nbd.c:nbd_receive_negociate():L501: read failed
> qemu-img: /var/tmp/v2vvovblahbla.qcow2: could not open
> 'nbd:localhost:55756': could not open image: invalid argument:
> invalid argument
> 
> then other blahblahblah before closing.
You need to post the complete debug log.  It's in /tmp on the
conversion server.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

Le 19/11/2014 16:33, Richard W.M. Jones a écrit :
> You need to post the complete debug log.  It's in /tmp on the
> conversion server.
Ah nice, I ignored that. Here it is:

virt-v2v: libguestfs 1.28.1 (x86_64)
[   0.0] Opening the source -i libvirtxml 
/tmp/virt-p2v-20141119-z1eg0fua/physical.xml
libvirt xml is:
<?xml version="1.0"?>
<!-- NOTE!

   This libvirt XML is generated by the virt-p2v front end, in
   order to communicate with the backend virt-v2v process running
   on the conversion server.  It is a minimal description of the
   physical machine.  If the target of the conversion is libvirt,
   then virt-v2v will generate the real target libvirt XML, which
   has only a little to do with the XML in this file.

   TL;DR: Don't try to load this XML into libvirt. -->
<domain type="physical">
   <name>bonjour</name>
   <memory unit="KiB">4194304</memory>
   <currentMemory unit="KiB">4194304</currentMemory>
   <vcpu>2</vcpu>
   <os>
     <type arch="x86_64">hvm</type>
   </os>
   <features>
     <acpi/>
     <apic/>
     <pae/>
   </features>
   <devices>
     <disk type="network" device="disk">
       <driver name="qemu" type="raw"/>
       <source protocol="nbd">
         <host name="localhost" port="33363"/>
       </source>
       <target dev="sda"/>
     </disk>
     <disk type="network" device="disk">
       <driver name="qemu" type="raw"/>
       <source protocol="nbd">
         <host name="localhost" port="49584"/>
       </source>
       <target dev="sdb"/>
     </disk>
     <disk type="network" device="disk">
       <driver name="qemu" type="raw"/>
       <source protocol="nbd">
         <host name="localhost" port="41988"/>
       </source>
       <target dev="sdc"/>
     </disk>
   </devices>
</domain>

     source name: bonjour
hypervisor type: physical
          memory: 4294967296 (bytes)
        nr vCPUs: 2
    CPU features: pae,apic,acpi
         display:
disks:
	nbd:localhost:33363 (raw) [sda]
	nbd:localhost:49584 (raw) [sdb]
	nbd:localhost:41988 (raw) [sdc]
removable media:

NICs:

[   0.0] Creating an overlay to protect the source from being modified
qemu-img create -q -f qcow2 -b 'nbd:localhost:33363' -o 
'compat=1.1,backing_fmt=raw' /var/tmp/v2vovl636444.qcow2
nbd.c:nbd_receive_negotiate():L501: read failed
qemu-img: /var/tmp/v2vovl636444.qcow2: Could not open 
'nbd:localhost:33363': Could not open image: Invalid argument: Invalid 
argument
virt-v2v: error: qemu-img command failed, see earlier errors

If reporting bugs, run virt-v2v with debugging enabled and include the
complete output:

   virt-v2v -v -x [...]


-- 
Nicolas Ecarnot