Created attachment 1689831 [details] conversion log Description of problem: Virt-v2v cannot convert guest from ESXI7.0 server without vddk Version-Release number of selected component (if applicable): virt-v2v-1.40.2-22.module+el8.3.0+6423+e4cb6418.x86_64 libguestfs-1.40.2-22.module+el8.3.0+6423+e4cb6418.x86_64 VMware-vix-disklib-6.7.3-14389676.x86_64.tar.gz How reproducible: 100% Steps to Reproduce: 1.Convert a guest from ESXI7.0 server # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.2-x86_64 -o rhv -os 10.66.144.40:/home/nfs_export -ip /home/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.2-x86_64 'curl' -q --max-redirs '5' --globoff --head --silent --url 'https://10.73.198.169/folder/esx7.0-rhel8.2-x86%5f64/esx7.0-rhel8.2-x86%5f64-flat.vmdk?dcPath=data&dsName=esx7.0-matrix' --user <hidden> --insecure HTTP/2 200 date: Tue, 19 May 2020 09:07:26 GMT set-cookie: vmware_soap_session="518c23795096a6ea558373f20d8ccc905e0a1ee1"; Path=/; HttpOnly; Secure; accept-ranges: bytes content-security-policy: block-all-mixed-content content-type: application/octet-stream strict-transport-security: max-age=31536000 x-content-type-options: nosniff x-frame-options: DENY x-xss-protection: 1 content-length: 12884901888 x-envoy-upstream-service-time: 420 server: envoy virt-v2v: error: vcenter: invalid response from server If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Actual results: As above Expected results: Virt-v2v can convert guest from ESXI7.0 server without vddk Additional info: virt-v2v can convert guest from ESXI7.0 server with vddk.
Looks real. I bet they've changed/broken the URLs ...
(In reply to liuzi from comment #0) > 'curl' -q --max-redirs '5' --globoff --head --silent --url > 'https://10.73.198.169/folder/esx7.0-rhel8.2-x86%5f64/esx7.0-rhel8.2- > x86%5f64-flat.vmdk?dcPath=data&dsName=esx7.0-matrix' --user <hidden> > --insecure > HTTP/2 200 > date: Tue, 19 May 2020 09:07:26 GMT > set-cookie: vmware_soap_session="518c23795096a6ea558373f20d8ccc905e0a1ee1"; > Path=/; HttpOnly; Secure; > accept-ranges: bytes > content-security-policy: block-all-mixed-content > content-type: application/octet-stream > strict-transport-security: max-age=31536000 > x-content-type-options: nosniff > x-frame-options: DENY > x-xss-protection: 1 > content-length: 12884901888 > x-envoy-upstream-service-time: 420 > server: envoy What I see above is that vCenter replies HTTP/2, and that status string is what virt-v2v tries to parse as "HTTP/x.y nnn" string, which obviously fail. I will have a try to improve the parsing of the HTTP status string.
Hopefully simple patch posted: https://www.redhat.com/archives/libguestfs/2020-May/msg00036.html Note that also the fix for bug 1837337 will be needed to test this, as otherwise nbdkit will not be able to parse HTTP response headers in a case-insensitive way.
Fixed upstream with https://github.com/libguestfs/virt-v2v/commit/d2aa82317964d62fcc8dc7b6737773003d04b998
After discussion with Martin T, we decided this bug should be moved to RHEL AV.
I can reproduce the bug with below builds: virt-v2v-1.42.0-3.module+el8.3.0+6497+b190d2a5.x86_64 libguestfs-1.42.0-1.module+el8.3.0+6496+d39ac712.x86_64 libvirt-6.3.0-1.module+el8.3.0+6478+69f490bb.x86_64 qemu-kvm-5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64
BTW I checked out Pino's virt-v2v patch together with my nbdkit patch (both with upstream builds) and was able to do a full conversion.
Test bug with builds: virt-v2v-1.40.2-23.module+el8.2.1+6797+0db00a40.x86_64 libguestfs-1.40.2-23.module+el8.2.1+6797+0db00a40.x86_64 Steps: 1.Convert a guest from ESXI7.0 to rhv without VDDK # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.2-x86_64 -o rhv -os 10.66.144.40:/home/nfs_export -ip /home/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.2-x86_64 [ 1.7] Creating an overlay to protect the source from being modified qemu-img: /var/tmp/v2vovl56bced.qcow2: CURL: Error opening file: Server does not support 'range' (byte ranges). Could not open backing image to determine size. 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 [...] Result:virt-v2v cannot convert guest form esxi7.0 without vddk.
Created attachment 1692923 [details] 0528-conversion log
(In reply to liuzi from comment #15) > Test bug with builds: > virt-v2v-1.40.2-23.module+el8.2.1+6797+0db00a40.x86_64 > libguestfs-1.40.2-23.module+el8.2.1+6797+0db00a40.x86_64 Please see bug 1837337, which is needed as well.
Verify bug with builds: virt-v2v-1.40.2-23.module+el8.2.1+6797+0db00a40.x86_64 libguestfs-1.40.2-23.module+el8.2.1+6797+0db00a40.x86_64 nbdkit-1.16.2-4.module+el8.2.1+6710+effcb1df.x86_64 qemu-kvm-4.2.0-24.module+el8.2.1+6959+9b840e7c.x86_64 Steps: Scenario 1:Convert a rhel guest from ESXI7.0 to RHV without vddk: # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.2-x86_64 -o rhv -os 10.66.144.40:/home/nfs_export -ip /home/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.2-x86_64 [ 1.6] Creating an overlay to protect the source from being modified [ 2.1] Opening the overlay [ 24.7] Inspecting the overlay [ 142.7] Checking for sufficient free disk space in the guest [ 142.7] Estimating space required on target for each disk [ 142.7] Converting Red Hat Enterprise Linux 8.2 (Ootpa) to run on KVM virt-v2v: warning: guest tools directory ‘linux/el8’ is missing from the virtio-win directory or ISO. Guest tools are only provided in the RHV Guest Tools ISO, so this can happen if you are using the version of virtio-win which contains just the virtio drivers. In this case only virtio drivers can be installed in the guest, and installation of Guest Tools will be skipped. virt-v2v: This guest has virtio drivers installed. [1395.2] Mapping filesystem data to avoid copying unused and blank areas [1397.5] Closing the overlay [1397.8] Assigning disks to buses [1397.8] Checking if the guest needs BIOS or UEFI to boot [1397.8] Initializing the target -o rhv -os 10.66.144.40:/home/nfs_export [1398.4] Copying disk 1/1 to /tmp/v2v.XbPNhl/5792ab14-7746-4340-a27d-845dc12b8db9/images/d2b68c18-08b6-46a8-8cde-d95ff2cdc5d0/baa7869f-7020-40ad-892a-ac3cbaefb1c0 (raw) (100.00/100%) [2379.0] Creating output metadata [2379.2] Finishing off Result 1:virt-v2v can convert guest successfully,and guest can pass normal checkpoints. Scenario 2:convert a windows guest from ESXI7.0 to RHV # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-x86_64 -o rhv -os 10.66.144.40:/home/nfs_export -ip /home/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-x86_64 [ 1.7] Creating an overlay to protect the source from being modified [ 2.1] Opening the overlay [ 17.0] Inspecting the overlay [ 135.5] Checking for sufficient free disk space in the guest [ 135.5] Estimating space required on target for each disk [ 135.5] Converting Windows Server 2019 Standard to run on KVM virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing. Firstboot scripts may conflict with PnP. virt-v2v: warning: QEMU Guest Agent MSI not found on tools ISO/directory. You may want to install the guest agent manually after conversion. virt-v2v: warning: there are no virtio drivers available for this version of Windows (10.0 x86_64 Server). virt-v2v looks for drivers in /usr/share/virtio-win The guest will be configured to use slower emulated devices. virt-v2v: This guest does not have virtio drivers installed. [ 149.1] Mapping filesystem data to avoid copying unused and blank areas [ 150.2] Closing the overlay [ 150.5] Assigning disks to buses [ 150.5] Checking if the guest needs BIOS or UEFI to boot [ 150.5] Initializing the target -o rhv -os 10.66.144.40:/home/nfs_export [ 150.8] Copying disk 1/1 to /tmp/v2v.QiIxGP/5792ab14-7746-4340-a27d-845dc12b8db9/images/bf1deb79-387c-45ab-91a4-5a2f6f48dc7e/2cce187b-3a19-4398-ae54-474cbe2d3834 (raw) (100.00/100%) [2098.5] Creating output metadata [2098.7] Finishing off Result 2:virt-v2v can convert guest successfully,and guest can pass normal checkpoints. Scenario 3:Use non-admin user to convert a rhel guest from ESXI7.0 to RHV without vddk: # virt-v2v -ic vpx://vsphere.local%5clz.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.2-x86_64 -o rhv -os 10.66.144.40:/home/nfs_export -ip /home/passwd [ 0.0] Opening the source -i libvirt -ic vpx://vsphere.local%5clz.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.2-x86_64 [ 1.7] Creating an overlay to protect the source from being modified [ 2.2] Opening the overlay [ 25.0] Inspecting the overlay [ 143.4] Checking for sufficient free disk space in the guest [ 143.4] Estimating space required on target for each disk [ 143.4] Converting Red Hat Enterprise Linux 8.2 (Ootpa) to run on KVM virt-v2v: warning: guest tools directory ‘linux/el8’ is missing from the virtio-win directory or ISO. Guest tools are only provided in the RHV Guest Tools ISO, so this can happen if you are using the version of virtio-win which contains just the virtio drivers. In this case only virtio drivers can be installed in the guest, and installation of Guest Tools will be skipped. virt-v2v: This guest has virtio drivers installed. [1395.9] Mapping filesystem data to avoid copying unused and blank areas [1398.1] Closing the overlay [1398.4] Assigning disks to buses [1398.4] Checking if the guest needs BIOS or UEFI to boot [1398.4] Initializing the target -o rhv -os 10.66.144.40:/home/nfs_export [1401.0] Copying disk 1/1 to /tmp/v2v.nW2DaR/5792ab14-7746-4340-a27d-845dc12b8db9/images/e5808d3f-2732-47e9-815c-f2d684a1ce8d/5e4054d3-866b-422a-93f8-b9d7fa4e388a (raw) (100.00/100%) [2491.4] Creating output metadata [2491.8] Finishing off Result 3:virt-v2v can convert guest successfully,and guest can pass normal checkpoints. Result:virt-v2v can convert guest from ESXI7.0 successfully without vddk,so change bug status 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/RHBA-2020:3172