Bug 2033096

Created attachment 1861298 [details]
0001-UNFINISHED-o-rhv-upload-Replace-oo-rhv-direct-with-o.patch

I had a go at implementing this, but I couldn't work out how to
change the oVirt API stuff.  Partial patch attached.

An easier change would be to flip the default from -oo rhv-direct=false -> true.
Is there some reason why specifying a different proxy host is useful?

https://listman.redhat.com/archives/libguestfs/2022-February/msg00216.html

Summary of IRC discussion because the bug description is unclear.

The new feature is just to add new "-oo rhv-proxy" boolean option.
You can use "-oo rhv-proxy" or "-oo rhv-proxy=true" (both do
the same thing).  Or "-oo rhv-proxy=false".

The default is changed so that now be that direct (non-proxy)
connections are the default.

If you use "-oo rhv-proxy", then connections are not direct, they
are proxied through the oVirt Engine.

The old "-oo rhv-direct" option is no longer documented, but
is still available for backwards compatibility.

Do you think specifying '-oo rhv-direct' and '-oo rhv-proxy' together should be forbidden?
If users do that, the later one will overwrite the previous one?

I wouldn't recommend it.  One of them will take priority, either the
first or the second, but I'm not sure which.

Steps to Reproduce:

Verified with the version: virt-v2v-1.45.99-1.el9.x86_64

Steps:
1. Check that the -oo rhv-direct option has gone.

There is no "-oo rhv-direct" in virt-v2v manual page.

2. Check that the new -oo rhv-proxy=<HOST> option has been added.
#man virt-v2v
....
       -oo rhv-proxy
           For -o rhv-upload (virt-v2v-output-rhv(1)) only, proxy the upload through oVirt Engine.  This is slower than uploading directly to
           the oVirt node but may be necessary if you do not have direct network access to the nodes.
....

3. Check that virt-v2v works without any -oo rhv-proxy option being used.(The old "-oo rhv-direct" option is no longer documented, but
is still available for backwards compatibility.)

# virt-v2v -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -o rhv-upload -of raw -os nfs_data -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /v2v-ops/rhvpasswd -oo rhv-cafile=/v2v-ops/ca22.pem -oo rhv-cluster=Default -oo rhv-direct --mac 00:50:56:ac:62:28:bridge:ovirtmgmt esx7.0-rhel8.5-x86_64 -it vddk -io vddk-libdir=/root/vddk_libdir/latest -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 --ip /v2v-ops/esxpw
[   0.0] Setting up the source: -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk esx7.0-rhel8.5-x86_64
[   1.8] Opening the source
[   8.8] Inspecting the source
[  17.7] Checking for sufficient free disk space in the guest
[  17.7] Converting Red Hat Enterprise Linux 8.5 (Ootpa) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  89.4] Mapping filesystem data to avoid copying unused and blank areas
[  89.9] Closing the overlay
[  90.1] Assigning disks to buses
[  90.1] Checking if the guest needs BIOS or UEFI to boot
[  90.1] Setting up the destination: -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data
[ 101.8] Copying disk 1/1
█ 100% [****************************************]
[ 380.2] Creating output metadata
[ 388.7] Finishing off


4. Check that virt-v2v works if -oo rhv-proxy is used.

# virt-v2v -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -o rhv-upload -oo rhv-proxy -of raw -os nfs_data -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /v2v-ops/rhvpasswd -oo rhv-cafile=/v2v-ops/ca22.pem -oo rhv-cluster=Default esx7.0-win2022-x86_64 -it vddk -io vddk-libdir=/root/vddk_libdir/latest -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 --ip /v2v-ops/esxpw
[   0.0] Setting up the source: -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk esx7.0-win2022-x86_64
[   1.6] Opening the source
[   6.4] Inspecting the source
[  11.4] Checking for sufficient free disk space in the guest
[  11.4] Converting Windows Server 2022 Standard to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  18.4] Mapping filesystem data to avoid copying unused and blank areas
[  19.5] Closing the overlay
[  19.7] Assigning disks to buses
[  19.7] Checking if the guest needs BIOS or UEFI to boot
[  19.7] Setting up the destination: -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data
[  40.3] Copying disk 1/1
█ 100% [****************************************]
[ 436.3] Creating output metadata
[ 447.5] Finishing off

# virt-v2v -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -o rhv-upload -oo rhv-proxy=false -of raw -os nfs_data -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /v2v-ops/rhvpasswd -oo rhv-cafile=/v2v-ops/ca22.pem -oo rhv-cluster=Default esx7.0-win11-x86_64 -it vddk -io vddk-libdir=/root/vddk_libdir/latest -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 --ip /v2v-ops/esxpw
[   0.0] Setting up the source: -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk esx7.0-win11-x86_64
[   1.7] Opening the source
[   5.8] Inspecting the source
[  10.0] Checking for sufficient free disk space in the guest
[  10.0] Converting Windows 10 Enterprise to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  13.5] Mapping filesystem data to avoid copying unused and blank areas
[  14.8] Closing the overlay
[  15.1] Assigning disks to buses
[  15.1] Checking if the guest needs BIOS or UEFI to boot
[  15.1] Setting up the destination: -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data
[  34.5] Copying disk 1/1
█ 100% [****************************************]
[ 629.4] Creating output metadata
[ 641.6] Finishing off


5. Check that virt-v2v works if both options are specified.

# virt-v2v -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -o rhv-upload -oo rhv-proxy -oo rhv-direct -of raw -os nfs_data -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /v2v-ops/rhvpasswd -oo rhv-cafile=/v2v-ops/ca22.pem -oo rhv-cluster=Default esx7.0-win11-x86_64 -it vddk -io vddk-libdir=/root/vddk_libdir/latest -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 --ip /v2v-ops/esxpw
[   0.0] Setting up the source: -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk esx7.0-win11-x86_64
[   1.8] Opening the source
[   6.3] Inspecting the source
[  10.8] Checking for sufficient free disk space in the guest
[  10.8] Converting Windows 10 Enterprise to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  14.9] Mapping filesystem data to avoid copying unused and blank areas
[  16.2] Closing the overlay
[  16.4] Assigning disks to buses
[  16.4] Checking if the guest needs BIOS or UEFI to boot
[  16.4] Setting up the destination: -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data
[  28.0] Copying disk 1/1
█ 100% [****************************************]
[ 788.5] Creating output metadata
[ 800.9] Finishing off


Moving 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 (new packages: virt-v2v), 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-2022:2566