Bug 1837328

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