Created attachment 1439471 [details] v2v_1.38.2-1-qemu-kvm_7.5.z-null.log Description of problem: virt-v2v rhel7.6 build can't convert guest to null with qemu-kvm rhel7.5.z build Version-Release number of selected component (if applicable): virt-v2v-1.38.2-1.el7.x86_64 libguestfs-1.38.2-1.el7.x86_64 libvirt-3.9.0-14.el7_5.5.x86_64 qemu-kvm-1.5.3-156.el7_5.2.x86_64 How reproducible: 100% Steps to Reproduce: 1.Convert a guest to null by virt-v2v # virt-v2v rhel7.5 -o null [ 0.0] Opening the source -i libvirt rhel7.5 [ 0.0] Creating an overlay to protect the source from being modified [ 0.5] Initializing the target -o null [ 0.5] Opening the overlay [ 4.1] Inspecting the overlay [ 270.4] Checking for sufficient free disk space in the guest [ 270.4] Estimating space required on target for each disk [ 270.4] Converting Red Hat Enterprise Linux Server 7.5 (Maipo) to run on KVM virt-v2v: This guest has virtio drivers installed. [ 527.5] Mapping filesystem data to avoid copying unused and blank areas [ 530.4] Closing the overlay [ 535.3] Checking if the guest needs BIOS or UEFI to boot [ 535.3] Assigning disks to buses [ 535.3] Copying disk 1/1 to qemu URI json:{ "file.driver": "null-co", "file.size": "1E" } (raw) qemu-img: Unknown protocol 'json:{ "file.driver": "null-co", "file.size": "1E" }' 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 [...] Actual results: As above description Expected results: virt-v2v rhel7.6 build can convert guest to null with qemu-kvm rhel7.5.z build Additional info: 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 libvirt-3.9.0-14.el7_5.5.x86_64
This is horrible but I guess the only fix here is to downstream revert commit 4699c7b6e126e07c95b67fb95df58aed87a680dd in RHEL 7 only.
(In reply to Richard W.M. Jones from comment #3) > This is horrible but I guess the only fix here is to downstream revert > commit 4699c7b6e126e07c95b67fb95df58aed87a680dd in RHEL 7 only. An alternative is to detect at runtime whether qemu-img supports both JSON URLs, and the null-co driver, and only if so use the current way (i.e. revert to copying-and-discard like it was done before). We already do something similar for OVA, see qemu_img_supports_offset_and_size.
While that would certainly be nicer, it's also pretty complicated. I wonder if we need this complexity for what is essentially a debugging/testing feature?
Not-that-complicated (at least IMHO) approach for this: https://www.redhat.com/archives/libguestfs/2018-May/msg00093.html
Fixed upstream with https://github.com/libguestfs/libguestfs/commit/1b6a2b221d04e455bdd31cff09015f74487882c1 which is in libguestfs >= 1.39.6.
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 to null by virt-v2v # virt-v2v rhel7.5 -o null [ 0.0] Opening the source -i libvirt rhel7.5 [ 0.1] Creating an overlay to protect the source from being modified [ 1.6] Initializing the target -o null [ 2.1] Opening the overlay [ 10.4] Inspecting the overlay [ 93.8] Checking for sufficient free disk space in the guest [ 93.8] Estimating space required on target for each disk [ 93.8] Converting Red Hat Enterprise Linux Server 7.5 (Maipo) to run on KVM virt-v2v: This guest has virtio drivers installed. [ 314.6] Mapping filesystem data to avoid copying unused and blank areas [ 317.2] Closing the overlay [ 325.7] Checking if the guest needs BIOS or UEFI to boot [ 325.7] Assigning disks to buses [ 325.7] Copying disk 1/1 to /var/tmp/null.SGwPbX/sda (raw) (100.00/100%) [ 673.4] Creating output metadata [ 673.4] Finishing off Result: Latest Virt-v2v could convert guest to null target with qemu-kvm rhel7.5.z build,so move the 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