+++ This bug was initially created as a clone of Bug #1837328 +++ 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. --- Additional comment from Richard W.M. Jones on 2020-05-19 11:48:15 CEST --- Looks real. I bet they've changed/broken the URLs ... --- Additional comment from Pino Toscano on 2020-05-19 11:57:39 CEST --- (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. --- Additional comment from Pino Toscano on 2020-05-19 12:21:21 CEST --- 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. --- Additional comment from Pino Toscano on 2020-05-19 13:35:23 CEST --- Fixed upstream with https://github.com/libguestfs/virt-v2v/commit/d2aa82317964d62fcc8dc7b6737773003d04b998 --- Additional comment from Richard W.M. Jones on 2020-05-19 14:29:22 CEST --- After discussion with Martin T, we decided this bug should be moved to RHEL AV. --- Additional comment from mxie on 2020-05-19 15:02:30 CEST --- 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 --- Additional comment from Richard W.M. Jones on 2020-05-21 13:15:32 CEST --- 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.42.0-4.module+el8.3.0+6798+ad6e66be.x86_64 libguestfs-1.42.0-2.module+el8.3.0+6798+ad6e66be.x86_64 Steps: 1.Convert a rhel guest from ESXI7.0 server to rhv without vddk option # 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 [ 2.7] Creating an overlay to protect the source from being modified [ 3.2] Opening the overlay [ 40.4] Inspecting the overlay [ 120.0] Checking for sufficient free disk space in the guest [ 120.0] Estimating space required on target for each disk [ 120.0] Converting Red Hat Enterprise Linux 8.2 (Ootpa) to run on KVM virt-v2v: This guest has virtio drivers installed. [1738.0] Mapping filesystem data to avoid copying unused and blank areas [1740.6] Closing the overlay [1740.9] Assigning disks to buses [1740.9] Checking if the guest needs BIOS or UEFI to boot [1740.9] Initializing the target -o rhv -os 10.66.144.40:/home/nfs_export [1741.0] Copying disk 1/1 to /tmp/v2v.sBm7Z9/5792ab14-7746-4340-a27d-845dc12b8db9/images/5577ea1b-de3c-4b4e-8a95-b59b3c33135e/072804a6-e06b-4672-bef3-05091e346bb6 (raw) (100.00/100%) [2365.0] Creating output metadata [2365.1] Finishing off Result1: conversion can be finished successfully,and the guest can pass regular checkpoints. Scenario2 :convert a windows 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-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 [ 2.9] Creating an overlay to protect the source from being modified [ 3.4] Opening the overlay [ 33.0] Inspecting the overlay [ 106.8] Checking for sufficient free disk space in the guest [ 106.8] Estimating space required on target for each disk [ 106.8] 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: there is no QXL driver for this version of Windows (10.0 x86_64). virt-v2v looks for this driver in /usr/share/virtio-win/virtio-win.iso The guest will be configured to use a basic VGA display driver. virt-v2v: This guest has virtio drivers installed. [ 205.3] Mapping filesystem data to avoid copying unused and blank areas [ 206.7] Closing the overlay [ 207.0] Assigning disks to buses [ 207.0] Checking if the guest needs BIOS or UEFI to boot [ 207.0] Initializing the target -o rhv -os 10.66.144.40:/home/nfs_export [ 207.2] Copying disk 1/1 to /tmp/v2v.527WZs/5792ab14-7746-4340-a27d-845dc12b8db9/images/61e7ceb3-5e38-4075-af1b-776bef4fba4c/8ab55924-e0b7-4d2f-844f-84b7b46c6347 (raw) (100.00/100%) [1021.5] Creating output metadata [1021.7] Finishing off Result2: conversion can be finished successfully,and the guest can pass regular checkpoints. Scenario3:convert a windows guest from ESXI7.0 to libvirt without vddk # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-x86_64 -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 [ 3.9] Creating an overlay to protect the source from being modified [ 4.4] Opening the overlay [ 29.2] Inspecting the overlay [ 103.7] Checking for sufficient free disk space in the guest [ 103.7] Estimating space required on target for each disk [ 103.7] 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: there is no QXL driver for this version of Windows (10.0 x86_64). virt-v2v looks for this driver in /usr/share/virtio-win/virtio-win.iso The guest will be configured to use a basic VGA display driver. virt-v2v: This guest has virtio drivers installed. [ 201.0] Mapping filesystem data to avoid copying unused and blank areas [ 202.3] Closing the overlay [ 202.6] Assigning disks to buses [ 202.6] Checking if the guest needs BIOS or UEFI to boot [ 202.6] Initializing the target -o libvirt -os default [ 202.7] Copying disk 1/1 to /var/lib/libvirt/images/esx7.0-win2019-x86_64-sda (raw) (100.00/100%) [ 976.1] Creating output metadata [ 976.1] Finishing off Result:Virt-v2v can convert guest from ESXI7.0 server to rhv without vddk,and the guest can pass regular check.So change 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 (virt:8.3 bug fix and enhancement update), 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:5137