Bug 1430287

(In reply to kuwei from comment #0)
> 1:Convert a rhel7.2 guest from vmware to kvm.
> # #  virt-v2v -ic vpx://root.75.182/data/10.73.3.19/?no_verify=1
> esx5.5-rhel7.2-x86_64 --password-file /tmp/passwd -on test1
> [   0.0] Opening the source -i libvirt -ic
> vpx://root.75.182/data/10.73.3.19/?no_verify=1 esx5.5-rhel7.2-x86_64
> [   1.2] Creating an overlay to protect the source from being modified
> [   1.8] Initializing the target -o libvirt -os default
> [   1.8] Opening the overlay
> [  35.0] Inspecting the overlay
> ^c

In this case, there I/O errors when reading the disks, and most probably that causes the kernel to throw error traces. My guess is that it is an issue either in QEMU (the curl/https driver), or in the kernel.

Can you please paste the result of `rpm -qa | grep kernel | sort -V`, on the host where virt-v2v was run?
I see you are using qemu-kvm-rhev, could you please try with the plain qemu-kvm?

> 2.Convert a windows guest from vmware to kvm.

Can you please provide the logs for this case?

(In reply to Pino Toscano from comment #2)

> In this case, there I/O errors when reading the disks, and most probably
> that causes the kernel to throw error traces. My guess is that it is an
> issue either in QEMU (the curl/https driver), or in the kernel.
> 
> Can you please paste the result of `rpm -qa | grep kernel | sort -V`, on the
> host where virt-v2v was run?
# rpm -qa | grep kernel | sort -V
kernel-3.10.0-567.el7.x86_64
kernel-devel-3.10.0-567.el7.x86_64
kernel-headers-3.10.0-567.el7.x86_64
kernel-tools-3.10.0-567.el7.x86_64
kernel-tools-libs-3.10.0-567.el7.x86_64

> I see you are using qemu-kvm-rhev, could you please try with the plain
> qemu-kvm?

Using qemu-kvm can convert guest from vmware to kvm successfully,you can see my addition info comment 0. But we can't start the guest on qemu-kvm packages,it is a bug https://bugzilla.redhat.com/show_bug.cgi?id=1430214.I think the bug maybe some help.

> > 2.Convert a windows guest from vmware to kvm.
> 
> Can you please provide the logs for this case?

Created attachment 1261197 [details]
v2v-windows

(In reply to kuwei from comment #3)
> > I see you are using qemu-kvm-rhev, could you please try with the plain
> > qemu-kvm?
> 
> Using qemu-kvm can convert guest from vmware to kvm successfully,you can see
> my addition info comment 0.

Oh you are right, sorry.

> But we can't start the guest on qemu-kvm
> packages,it is a bug https://bugzilla.redhat.com/show_bug.cgi?id=1430214.I
> think the bug maybe some help.

This is a libvirt 3.1.0 regression, see bug 1430258.

You should be able to work around it by explicitly using the direct backend:
export LIBGUESTFS_BACKEND=direct

(Remember to drop this workaround once the libvirt bug is fixed.)

> > > 2.Convert a windows guest from vmware to kvm.
> > 
> > Can you please provide the logs for this case?

Hmm... does it work if by chance you install libguestfs-rescue together with virt-v2v? It looks like lsof might needed by the base library, because of a local workaround.

The timeout happens after 2000 seconds, which happens to be the
timeout that we set in the qemu curl driver:

https://github.com/libguestfs/libguestfs/blob/0b793550d430cd8135c177f74dec13341c731b6d/v2v/vCenter.ml#L224

In qemu commit

http://git.qemu-project.org/?p=qemu.git;a=commit;h=796a060bc0fab40953997976a2e30d9d6235bc7b

I changed the curl driver so it's now supposed to print the underlying
error if there is one.  Since that didn't happen in this case, I
conclude that the curl driver really is hitting the timeout, and
there is not any other error.

While we could increase the timeout again (it was previously
increased from 600 - see bug 1146007), it's not clear to me
that we should be hitting the timeout at all.  That would
indicate that the XFS driver in the kernel isn't reading or
writing any data over the connection for 2000 seconds, but is
instead either hung or doing some kind of processing.

I obtained the source image from the source server.

However I was able to open the disk locally just fine, both with
Fedora 26 and RHEL 7.4-preview, so I don't really know what's
going on here.

On RHEL 7.4 I am using:

kernel-3.10.0-567.el7.x86_64
10:qemu-kvm-rhev-2.8.0-5.el7.x86_64

I also tried qemu-kvm-1.5.3-126.el7.x86_64

Hi, rjones, 
i try some different qemu-kvm-rhev versions and virt-v2v to convert guest from vmware to kvm, below list is the result.

Scenario 1: 
when i using   qemu-kvm-rhev-2.8.0-5.el7.x86_64,   
virt-v2v-1.36.1-1.el7.x86_64, --- failed 
virt-v2v-1.36.2-1.el7.x86_64 , ---failed
virt-v2v-1.32.7-3.el7.x86_64  --- failed.

Scenario 2:
Using    qemu-kvm-rhev-2.8.0-6.el7.x86_64,  
virt-v2v-1.36.1-1.el7.x86_64,--- passed  
virt-v2v-1.36.2-1.el7.x86_64 --- passed.

Scenario 3: 
Using qemu-kvm-rhev-2.6.0-28.el7_3.6.x86_64,
virt-v2v-1.36.2-1.el7.x86_64 , ---passed


So, I think qemu-kvm-rhev-2.8.0-5.el7.x86_64 maybe has some issues.

qemu-kvm-rhev 2.8.0-6 fixes bug 1425700, something to do with
the handling of virtio-scsi queues.  It is plausible that this
change may have fixed this bug.

I am going to test the -6 package myself using the reproducer
in comment 10.  Let's keep this bug open to see if the bug
appears again.

Can confirm that this appears to be fixed by
qemu-kvm-rhev-2.8.0-6.el7.

On that basis I will mark it as a duplicate of bug 1425700.

*** This bug has been marked as a duplicate of bug 1425700 ***