Bug 1580292

Created attachment 1439443 [details]
v2v_1.38.1-1-rhel7.5.z_qemu-kvm.log

Any errors about the ‘null-co’ driver (presumably related
to using ‘-o null’) should be filed under a new BZ.

(In reply to Richard W.M. Jones from comment #4)
> Any errors about the ‘null-co’ driver (presumably related
> to using ‘-o null’) should be filed under a new BZ.

I just want to add a comment to explain the error ""qemu-img: Unknown protocol" got from null target, thanks for your reminding, I will file a new bug to track this problem

(In reply to mxie from comment #5)
> (In reply to Richard W.M. Jones from comment #4)
> > Any errors about the ‘null-co’ driver (presumably related
> > to using ‘-o null’) should be filed under a new BZ.
> 
> I just want to add a comment to explain the error ""qemu-img: Unknown
> protocol" got from null target, thanks for your reminding, I will file a new
> bug to track this problem

Most probably this happens because qemu-kvm 1.5 does not have the null-co driver, whereas a newer qemu-kvm-rhev has it.  Also, I see the test uses qemu-kvm 1.5.

Do you still hit the same issues if you use qemu-kvm-rhev instead of qemu-kvm?

> Most probably this happens because qemu-kvm 1.5 does not have the null-co
> driver, whereas a newer qemu-kvm-rhev has it.  Also, I see the test uses
> qemu-kvm 1.5.
> 
> Do you still hit the same issues if you use qemu-kvm-rhev instead of
> qemu-kvm?

V2V can convert guest to null with builds:
virt-v2v-1.38.2-1.el7.x86_64
libguestfs-1.38.2-1.el7.x86_64
qemu-kvm-rhev-2.10.0-21.el7_5.3.x86_64

qemu-img convert (not qemu-img-rhev) does not support file:... URLs for
the output, eg:

$ truncate -s 1G test.raw
$ qemu-img convert -f raw test.raw -O qcow2 file:/tmp/test.qcow2
qemu-img: file:/tmp/test.qcow2: error while converting qcow2: Could not create file: No such file or directory
$ rpm -qf /usr/bin/qemu-img
qemu-img-1.5.3-141.el7.x86_64

This is a problem with virt-v2v 1.38 because of:

https://github.com/libguestfs/libguestfs/commit/e29296cfa20dd691995832940a30fe2e6b98149a

which adds the ‘file:’ prefix to the output name when converting to
a file.  This is right for recent QEMU but not for ancient QEMU 1.5.

A simple downstream patch for RHEL 7 should fix this:

v2v/v2v.ml:
      let cmd =
        let filename =
          match t.target_file with
-         | TargetFile filename -> "file:" ^ filename
+         | TargetFile filename -> filename
          | TargetURI uri -> uri in
        [ Guestfs_config.qemu_img; "convert" ] @

(In reply to Richard W.M. Jones from comment #8)
> A simple downstream patch for RHEL 7 should fix this:
> 
> v2v/v2v.ml:
>       let cmd =
>         let filename =
>           match t.target_file with
> -         | TargetFile filename -> "file:" ^ filename
> +         | TargetFile filename -> filename
>           | TargetURI uri -> uri in
>         [ Guestfs_config.qemu_img; "convert" ] @

This seems to work fine also on Fedora 28 with qemu 2.11 (both `make check`, and `make check-slow` in v2v/ work fine), so maybe this could be done upstream?

‘filename’ is badly named, it's really a URI.  So if we did change this
upstream then we'd minimally also want to protect the output filename
from being misinterpreted as a URI.  But with my upstream hat on I don't
want to support this ancient version of qemu at all.

(In reply to Richard W.M. Jones from comment #10)
> ‘filename’ is badly named, it's really a URI.  So if we did change this
> upstream then we'd minimally also want to protect the output filename
> from being misinterpreted as a URI.

I think we have qemu_input_filename in Std_utils to deal with this of situation -- would that be enough in this case?

Yes that's a better idea.  Here's the patch:

https://www.redhat.com/archives/libguestfs/2018-May/msg00099.html

Upstream in >= 1.39.6:

https://github.com/libguestfs/libguestfs/commit/0c934144eb8ea0ee1e1f68d4975415c001a62556

Verify the bug with below builds:
virt-v2v-1.38.2-2.el7.x86_64
libguestfs-1.38.2-2.el7.x86_64
libvirt-client-4.3.0-1.el7.x86_64
qemu-kvm-1.5.3-156.el7_5.2.x86_64
qemu-img-1.5.3-156.el7_5.2.x86_64


Steps:
1.Convert a guest from vmware to rhv by virt-v2v,conversion is finished without error and checkpoints of guest are passed
#  virt-v2v -ic vpx://root.75.182/data/10.73.72.61/?no_verify=1 esx6.0-rhel7.5-x86_64 -o rhv -os 10.66.144.40:/home/nfs_export -of qcow2 --password-file /tmp/passwd
[   0.0] Opening the source -i libvirt -ic vpx://root.75.182/data/10.73.72.61/?no_verify=1 esx6.0-rhel7.5-x86_64
[   2.1] Creating an overlay to protect the source from being modified
[   2.8] Initializing the target -o rhv -os 10.66.144.40:/home/nfs_export
[   3.1] Opening the overlay
[  82.8] Inspecting the overlay
[ 403.4] Checking for sufficient free disk space in the guest
[ 403.4] Estimating space required on target for each disk
[ 403.4] Converting Red Hat Enterprise Linux Server 7.5 (Maipo) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[1448.9] Mapping filesystem data to avoid copying unused and blank areas
[1451.3] Closing the overlay
[1452.3] Checking if the guest needs BIOS or UEFI to boot
[1452.3] Assigning disks to buses
[1452.3] Copying disk 1/1 to /tmp/v2v.aFHYm8/ea9cb06f-8bf9-4fc8-a247-478e754d898a/images/dc08f5a5-daf6-497f-8034-b1bd969ce86d/f93971be-4790-41fe-84e3-90a3414db665 (qcow2)
    (100.00/100%)
[2046.3] Creating output metadata
[2046.5] Finishing off


2.Convert a guest from xen to libvirt by virt-v2v,conversion is finished without error and checkpoints of guest are passed
# virt-v2v -ic xen+ssh://root.3.21 xen-hvm-rhel7.5-x86_64 -of raw
 

3.Convert a guest from vmware to rhv by virt-v2v via vmx,conversion is finished without error and checkpoints of guest are passed
# virt-v2v -i vmx esx6.7-win7-i386.vmx -o rhv -os 10.66.144.40:/home/nfs_export -of raw

Result:
   According above test result, latest virt-v2v can convert guest with qemu-kvm rhel7.5.z build, so move this bug from ON_QA to VERIFIED

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:3021