RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2033096 - RFE: Remove -oo rhv-direct and add -oo rhv-proxy option
Summary: RFE: Remove -oo rhv-direct and add -oo rhv-proxy option
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: virt-v2v
Version: 9.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Virtualization Maintenance
QA Contact: Vera
URL:
Whiteboard:
Depends On:
Blocks: 2032324
TreeView+ depends on / blocked
 
Reported: 2021-12-15 22:48 UTC by Richard W.M. Jones
Modified: 2022-05-17 13:43 UTC (History)
9 users (show)

Fixed In Version: virt-v2v-1.45.99-1.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-17 13:41:56 UTC
Type: Feature Request
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
0001-UNFINISHED-o-rhv-upload-Replace-oo-rhv-direct-with-o.patch (7.75 KB, patch)
2022-02-15 16:28 UTC, Richard W.M. Jones 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-105948 0 None Waiting on Customer Unable to register the system with VDC product. 2022-05-12 11:57:15 UTC
Red Hat Product Errata RHEA-2022:2566 0 None None None 2022-05-17 13:42:10 UTC

Description Richard W.M. Jones 2021-12-15 22:48:38 UTC 
Description of problem:

Currently virt-v2v -o rhv-upload has an option -oo rhv-direct.
If used, it enables direct connection to imageio.  If omitted
then it uses a proxy (which is much slower).

After some discussion with Nir we have decided this option is
really the wrong way round.  The user should not normally specify
any option and -o rhv-upload should try a direct connection.
If that fails in the less likely case that a proxy needs to
be used, the user can try again with a new -oo rhv-proxy
option (to select a proxy).

There is similar logic already in the imageio client:

https://github.com/oVirt/ovirt-imageio/blob/901ff9ad983ee6b19991dfc1e3da6a2ab0b05922/ovirt_imageio/client/_api.py#L510

Version-Release number of selected component (if applicable):

virt-v2v 1.45.93

Steps to Reproduce:

- Check that the -oo rhv-direct option has gone.

- Check that the new -oo rhv-proxy=<HOST> option has been added.

- Check that virt-v2v works without any -oo rhv-proxy option being used.

- Check that virt-v2v works if an explicit proxy host is specified.
Comment 4 Richard W.M. Jones 2022-02-15 16:28:22 UTC 
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.
Comment 5 Richard W.M. Jones 2022-02-15 16:29:10 UTC 
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?
Comment 6 Richard W.M. Jones 2022-02-15 17:09:34 UTC 
https://listman.redhat.com/archives/libguestfs/2022-February/msg00216.html
Comment 7 Richard W.M. Jones 2022-02-15 18:26:09 UTC 
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.
Comment 10 Xiaodai Wang 2022-02-16 06:37:02 UTC 
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?
Comment 11 Richard W.M. Jones 2022-02-16 10:14:52 UTC 
I wouldn't recommend it.  One of them will take priority, either the
first or the second, but I'm not sure which.
Comment 12 Vera 2022-02-17 05:55:56 UTC 

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.
Comment 14 errata-xmlrpc 2022-05-17 13:41:56 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 (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
Note You need to log in before you can comment on or make changes to this bug.