Setting ITR=9.2.0 and DTM=15 just to give a target. 

This needs to be completed before 15-Jan in order to be ready for Comprehensive Test Cycle 2

Let's include the fixes for https://bugzilla.redhat.com/show_bug.cgi?id=2151752 and https://bugzilla.redhat.com/show_bug.cgi?id=2152465 in this rebase. (The former's patch is upstream already, the latter's one has been tested by Vera Wu and is ready for upstreaming.)

The release notes for virt-v2v 2.2 are here:

https://libguestfs.org/virt-v2v-release-notes-2.2.1.html

Note the new "virt-v2v-inspector" tool.

There is also a new -o kubevirt mode, but it's very experimental
and requires manual editing of the output metadata to actually work
(IOW, this is expected to not really work well - it's a placeholder
until we put some automation around it in future).

Windows 11 should work everywhere now.

Test the bug with virt-v2v-2.2.0-1.el9.x86_64


Steps:

Scenario1: new virt-v2v-inspector tool tested by vwu

1.1  virt-v2v-inspector -i option
# virt-v2v-inspector -i disk RHEL-9.1.img
[   0.9] Setting up the source: -i disk RHEL-9.1.img
[   2.0] Opening the source
[   9.9] Inspecting the source
[  15.1] Checking for sufficient free disk space in the guest
[  15.1] Converting Red Hat Enterprise Linux 9.1 (Plow) to run on KVM
virt-v2v-inspector: warning: /files/boot/grub2/device.map/hd0 references 
unknown device "vda".  You may have to fix this entry manually after 
conversion.
virt-v2v-inspector: This guest has virtio drivers installed.
[  76.8] Mapping filesystem data to avoid copying unused and blank areas
[  78.3] Closing the overlay
[  78.6] Assigning disks to buses
[  78.6] Checking if the guest needs BIOS or UEFI to boot
<?xml version='1.0' encoding='utf-8'?>
<v2v-inspection>
  <!-- generated by virt-v2v-inspector 2.2.0rhel=9,release=1.el9 -->
  <program>virt-v2v-inspector</program>
  <package>virt-v2v</package>
  <version>2.2.0</version>
  <disks>
    <disk index='0'>
      <virtual-size>10737418240</virtual-size>
      <allocated estimated='true'>2378891264</allocated>
    </disk>
  </disks>
  <operatingsystem>
    <name>linux</name>
    <distro>rhel</distro>
    <osinfo>rhel9.1</osinfo>
    <arch>x86_64</arch>
    <major_version>9</major_version>
    <minor_version>1</minor_version>
    <package_format>rpm</package_format>
    <package_management>dnf</package_management>
    <product_name>Red Hat Enterprise Linux 9.1 (Plow)</product_name>
  </operatingsystem>
</v2v-inspection>

1.2 with -i -O output.xml option

1.2.1  # virt-v2v-inspector -i disk RHEL-9.1.img -O inspect-RHEL9.1-output.xml
[   0.0] Setting up the source: -i disk RHEL-9.1.img
[   1.1] Opening the source
[   5.8] Inspecting the source
[  11.5] Checking for sufficient free disk space in the guest
[  11.5] Converting Red Hat Enterprise Linux 9.1 (Plow) to run on KVM
virt-v2v-inspector: warning: /files/boot/grub2/device.map/hd0 references 
unknown device "vda".  You may have to fix this entry manually after 
conversion.
virt-v2v-inspector: This guest has virtio drivers installed.
[  69.2] Mapping filesystem data to avoid copying unused and blank areas
[  71.1] Closing the overlay
[  71.4] Assigning disks to buses
[  71.4] Checking if the guest needs BIOS or UEFI to boot
[  71.4] Finishing off

1.2.2 # cat inspect-RHEL9.1-output.xml 
<?xml version='1.0' encoding='utf-8'?>
<v2v-inspection>
  <!-- generated by virt-v2v-inspector 2.2.0rhel=9,release=1.el9 -->
  <program>virt-v2v-inspector</program>
  <package>virt-v2v</package>
  <version>2.2.0</version>
  <disks>
    <disk index='0'>
      <virtual-size>10737418240</virtual-size>
      <allocated estimated='true'>2378825728</allocated>
    </disk>
  </disks>
  <operatingsystem>
    <name>linux</name>
    <distro>rhel</distro>
    <osinfo>rhel9.1</osinfo>
    <arch>x86_64</arch>
    <major_version>9</major_version>
    <minor_version>1</minor_version>
    <package_format>rpm</package_format>
    <package_management>dnf</package_management>
    <product_name>Red Hat Enterprise Linux 9.1 (Plow)</product_name>
  </operatingsystem>
</v2v-inspection>

Result of scenario1: No new problem is found


Scenario2: new feature '-o kubevirt mode' tested by mxie

2.1 Convert a guest from VMware to '-o kubevirt' mode by v2v
# virt-v2v -ic vpx://root.212.149/data/10.73.212.36/?no_verify=1  -it vddk -io vddk-libdir=/home/vddk8.0.0 -io vddk-thumbprint=D1:03:96:7E:11:3D:7C:4C:B6:50:28:1B:63:74:B5:40:5F:9D:9F:94 -ip /home/passwd  esx8.0-rhel8.8-x86_64 -o kubevirt -os /home/esx8.0-rhel8.8-x86_64-kubervirt

2.2 Copy the files which is converted in step1.1 to OCP env, then try to create VM

2.2.1 # kubectl apply -f /home/esx8.0-rhel8.8-x86_64-kubervirt/esx8.0-rhel8.8-x86_64.yaml
error: error validating "/home/esx8.0-rhel8.8-x86_64-kubervirt/esx8.0-rhel8.8-x86_64.yaml": error validating data: ValidationError(VirtualMachineInstance.spec.domain.resources): unknown field "cpu" in io.kubevirt.v1.VirtualMachineInstance.spec.domain.resources; if you choose to ignore these errors, turn validation off with --validate=false

2.2.2 According to above error, the format of CPU and feature elements are wrong, correct then and try again

Before:
spec:
  domain:
    devices:
      disks:
      - disk:
          bus: virtio
        name: disk-0
    resources:
      requests:
        memory: 2048Mi
      cpu:
        cores: 1
      features:

After:
....
spec:
  domain:
    devices:
      disks:
      - disk:
          bus: virtio
        name: disk-0
    resources:
      requests:
        memory: 2048Mi
    cpu:
      cores: 1
    features:
....

# kubectl apply -f /home/esx8.0-rhel8.8-x86_64-kubervirt/esx8.0-rhel8.8-x86_64.yaml
The VirtualMachineInstance "esx8.0-rhel8.8-x86_64" is invalid: metadata.name: Invalid value: "esx8.0-rhel8.8-x86_64": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

2.2.3 According to above error, edit vm name, then try again
Before:
....
metadata:
  name: esx8.0-rhel8.8-x86_64
....

After :
....
metadata:
  name: esx8.0-rhel8.8-x86-64
....

# kubectl apply -f /home/esx8.0-rhel8.8-x86_64-kubervirt/esx8.0-rhel8.8-x86_64.yaml
The request is invalid: spec.volumes[0]: HostDisk feature gate is not enabled

2.2.4 According to the error, enable HostDisk feature gate for current namespace and create vmi again

# oc apply -f /home/esx8.0-rhel8.8-x86_64-kubervirt/esx8.0-rhel8.8-x86_64.yaml 
virtualmachineinstance.kubevirt.io/esx8.0-rhel8.8-x86-64 created

# oc get vmi
NAME                    AGE   PHASE        IP    NODENAME   READY
esx8.0-rhel8.8-x86-64   34m   Scheduling                    False

Result of scenario2:  Use bug2162332 to track the problem of step2.2.1 and step2.2.2, and VMI keep Scheduling after creating in step2.2.4, I don't know where the problem is， will keep debugging the problem


Scenario3: new option '-o kubevirt' tested by xiaodwan

3.1 # virt-v2v -i disk /var/lib/libvirt/images/a.img -o kubevirt -op /tmp/a
[   0.7] Setting up the source: -i disk /var/lib/libvirt/images/a.img
virt-v2v: error: -o local: -op option cannot be used in this output mode

If reporting bugs, run virt-v2v with debugging enabled and include the 
complete output:

  virt-v2v -v -x [...]

3.2 # virt-v2v -i disk /var/lib/libvirt/images/server.qcow2 -o kubevirt -of qcow2 -os /var/tmp/ -oo compressed
[   1.1] Setting up the source: -i disk /var/lib/libvirt/images/server.qcow2
virt-v2v: error: no -oo (output options) are allowed here

Result of scenario3:  xiaodwan will file new bugs to track the problem of step3.1 and step3.2


Scenario4:  'Rocky Linux guest support has been added' tested by tzheng

4.1 Convert a Rocky9 guest from VMware by v2v
# virt-v2v -ic vpx://root.212.149/data/10.73.212.36/?no_verify=1  -it vddk -io vddk-libdir=/home/vddk8.0.0 -io vddk-thumbprint=D1:03:96:7E:11:3D:7C:4C:B6:50:28:1B:63:74:B5:40:5F:9D:9F:94 -ip /home/passwd -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api  -op /home/rhvpasswd -os nfs_data rocky9
[   0.8] Setting up the source: -i libvirt -ic vpx://root.212.149/data/10.73.212.36/?no_verify=1 -it vddk rocky9
[   2.6] Opening the source
[  10.1] Inspecting the source
[  16.9] Checking for sufficient free disk space in the guest
[  16.9] Converting Rocky Linux 9.1 (Blue Onyx) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 142.3] Mapping filesystem data to avoid copying unused and blank areas
[ 143.2] Closing the overlay
[ 143.5] Assigning disks to buses
[ 143.5] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[ 143.5] Setting up the destination: -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data
[ 155.8] Copying disk 1/1
█ 100% [****************************************]
[ 364.5] Creating output metadata
[ 384.4] Finishing off

4.2 Convert a Rocky8 guest from VMware by v2v
# virt-v2v -ic vpx://root.212.149/data/10.73.212.36/?no_verify=1  -it vddk -io vddk-libdir=/home/vddk8.0.0 -io vddk-thumbprint=D1:03:96:7E:11:3D:7C:4C:B6:50:28:1B:63:74:B5:40:5F:9D:9F:94 -ip /home/passwd -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api  -op /home/rhvpasswd -os nfs_data Rocky8
[   0.1] Setting up the source: -i libvirt -ic vpx://root.212.149/data/10.73.212.36/?no_verify=1 -it vddk Rocky8
[   1.8] Opening the source
[   7.2] Inspecting the source
[  19.4] Checking for sufficient free disk space in the guest
[  19.4] Converting Rocky Linux 8.7 (Green Obsidian) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 144.2] Mapping filesystem data to avoid copying unused and blank areas
[ 145.1] Closing the overlay
[ 145.4] Assigning disks to buses
[ 145.4] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[ 145.4] Setting up the destination: -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data
[ 166.5] Copying disk 1/1
█ 100% [****************************************]
[ 393.2] Creating output metadata
[ 413.0] Finishing off

Result of scenario4: No new problem is found

Another two bugs were filed for '-o kubevirt'.

https://bugzilla.redhat.com/show_bug.cgi?id=2162441
https://bugzilla.redhat.com/show_bug.cgi?id=2162444

Did some random testing for virt-v2v-2.2.0-5.el9, all problems were found have been tracked by bugs, so move the bug to verified status

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-v2v 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-2023:2313