Bug 1840126

Summary: Virt-v2v cannot convert guest from ESXI7.0 server without vddk
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: Pino Toscano <ptoscano>
Component: virt-v2vAssignee: Pino Toscano <ptoscano>
Status: CLOSED ERRATA QA Contact: liuzi <zili>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.2CC: jsuchane, juzhou, mxie, mzhan, ptoscano, rjones, tyan, tzheng, virt-maint, xiaodwan, zili
Target Milestone: rcKeywords: Automation
Target Release: 8.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: V2V
Fixed In Version: virt-v2v-1.42.0-4.module+el8.3.0+6798+ad6e66be Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1837328 Environment:
Last Closed: 2020-11-17 17:48:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1837328, 1837337, 1841038    
Bug Blocks:    

Description Pino Toscano 2020-05-26 12:18:26 UTC 
+++ 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.
Comment 4 liuzi 2020-06-03 07:22:50 UTC 
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.
Comment 7 errata-xmlrpc 2020-11-17 17:48:38 UTC 
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