Bug 2069768

Created attachment 1869384 [details]
import-e38f63c5-d0f3-4996-b40d-d302e1864038-20220330T070833.log

Reproduce with steps in Comment 0.

Package version:

virt-v2v-1.42.0-18.module+el8.6.0+14480+c0a3aa0f.x86_64
libvirt-8.0.0-5.module+el8.6.0+14480+c0a3aa0f.x86_64
qemu-kvm-6.2.0-10.module+el8.6.0+14540+5dcf03db.x86_64
vdsm-4.40.100.2-1.el8ev.x86_64

RHV Server - Software Version:4.4.10.7-0.4.el8ev

Import log - import-e38f63c5-d0f3-4996-b40d-d302e1864038-20220330T070833.log

(In reply to zhoujunqin from comment #1)
> Created attachment 1869384 [details]
> import-e38f63c5-d0f3-4996-b40d-d302e1864038-20220330T070833.log
> 
> Reproduce with steps in Comment 0.
> 
> Package version:
> 
> virt-v2v-1.42.0-18.module+el8.6.0+14480+c0a3aa0f.x86_64
> libvirt-8.0.0-5.module+el8.6.0+14480+c0a3aa0f.x86_64
> qemu-kvm-6.2.0-10.module+el8.6.0+14540+5dcf03db.x86_64
> vdsm-4.40.100.2-1.el8ev.x86_64
> 
> RHV Server - Software Version:4.4.10.7-0.4.el8ev
> 
> Import log - import-e38f63c5-d0f3-4996-b40d-d302e1864038-20220330T070833.log

I can successfully import other OVA files, so I think the bug issue is only targeted on the specific OVA file, thanks.

I downloaded the OVA (protect_appliance.ova) and unpacked it to see what it contains:

$ tar xvf protect_appliance.ova
PROTECT_Appliance.ovf
PROTECT_Appliance.mf
PROTECT_Appliance.cert
PROTECT_Appliance-disk1.vmdk
$ qemu-img convert PROTECT_Appliance-disk1.vmdk -O raw PROTECT_Appliance-disk1.raw
$ guestfish --ro -a PROTECT_Appliance-disk1.raw -i
Operating system: CentOS Linux release 7.9.2009 (Core)
/dev/centos_ba-eraappl-v/root mounted on /
/dev/sda1 mounted on /boot
/dev/centos_ba-eraappl-v/home mounted on /home

So this is a supported guest type and should be importable
(https://access.redhat.com/articles/1351473).

The actual error though is a new one, and a real one in virt-v2v ...

$ tar tRvf protect_appliance.ova
...
block 75: -rw-r--r-- eraautobuilds/Domain Users 2632183808 2021-11-04 17:48 PROTECT_Appliance-disk1.vmdk
                                   ^^^^^^^^^^^^

The problem is that the group name contains a space.  When we search the output
of this for the VMDK file, we are not expecting the space (which appears to
add an extra field to the output):

https://github.com/libguestfs/virt-v2v/blob/482e74bb56a693758032b7566d5915f9e5531688/input/OVA.ml#L403

So yes this is a bug in virt-v2v.

Here's a simple reproducer:

$ virt-v2v -i ova protect_appliance.ova -o null
[   0.0] Setting up the source: -i ova protect_appliance.ova
virt-v2v: error: file ‘PROTECT_Appliance-disk1.vmdk’ not found in the 
ova

Luckily this was fairly easy to fix, and I verified that after this
fix we are able to import your OVA:

https://listman.redhat.com/archives/libguestfs/2022-April/028553.html

Moving to RHEL 9 because there's an easy workaround - simply unpack
the OVA, then repack it (with 'tar cf').  Assuming you don't use usernames
with spaces locally you should end up with an importable OVA.

Fixed in:
https://github.com/libguestfs/virt-v2v/commit/db00a9a9aa52e305fbdb6201ae1df33dc6bc425a

Built in C9S:
https://kojihub.stream.rdu2.redhat.com/koji/taskinfo?taskID=1056540

Test the workaround on RHEL-8.6(Registered as an RHV NODE) as Comment 4 said: PASS

1. Unpack files from the OVA file.
$ tar xvf protect_appliance.ova
PROTECT_Appliance.ovf
PROTECT_Appliance.mf
PROTECT_Appliance.cert
PROTECT_Appliance-disk1.vmdk

$ tar tRvf protect_appliance.ova
block 0: -rw-r--r-- eraautobuilds/Domain Users 33508 2021-11-04 13:48 PROTECT_Appliance.ovf
block 67: -rw-r--r-- eraautobuilds/Domain Users   147 2021-11-04 13:48 PROTECT_Appliance.mf
block 69: -rwxrwx--- Administrators/Domain Users 2414 2021-11-04 13:55 PROTECT_Appliance.cert
block 75: -rw-r--r-- eraautobuilds/Domain Users 2632183808 2021-11-04 13:48 PROTECT_Appliance-disk1.vmdk
block 5141060: ** Block of NULs **

The problem is that the group name(Domain Users) contains a space. 
                                   ^^^^^^^^^^^^^

2. Repack the files again (with 'tar cf') and ensure you don't use usernames with spaces locally.

$ tar cf test.ova *
$ tar tRvf test.ova
block 0: -rwxrwx--- juzhou/juzhou  2414 2021-11-04 13:55 PROTECT_Appliance.cert
block 6: -rw-r--r-- juzhou/juzhou 2632183808 2021-11-04 13:48 PROTECT_Appliance-disk1.vmdk
block 5140991: -rw-r--r-- juzhou/juzhou        147 2021-11-04 13:48 PROTECT_Appliance.mf
block 5140993: -rw-r--r-- juzhou/juzhou      33508 2021-11-04 13:48 PROTECT_Appliance.ovf

There is no space existing in the group name.

3. Change the permission of the new OVA file(test.ova)
# ll /home/test.ova 
-rwxrwxrwx. 1 vdsm kvm 2632232960 Apr  8 08:20 /home/test.ova

4. Operate on RHV Webadmin to create a new VM via importing from the ova file(/home/test.ova)

Test result: The OVA file can be imported to RHV successfully.

For RHEL 9.0.

1. Reproduce with virt-v2v-2.0.1-1.el9.x86_64

# virt-v2v -i ova protect_appliance.ova -o null
[   1.2] Setting up the source: -i ova protect_appliance.ova
virt-v2v: warning: making OVA directory public readable to work around 
libvirt bug https://bugzilla.redhat.com/1045069
virt-v2v: error: file ‘PROTECT_Appliance-disk1.vmdk’ not found in the 
ova

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

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

Test result: Failed to import OVA file.

2. Verified with virt-v2v-2.0.2-1.el9.x86_64

Test scenario-1: -o null

# virt-v2v -i ova protect_appliance.ova -o null
[   0.0] Setting up the source: -i ova protect_appliance.ova
virt-v2v: warning: making OVA directory public readable to work around 
libvirt bug https://bugzilla.redhat.com/1045069
[   4.5] Opening the source
[  11.5] Inspecting the source
[  16.2] Checking for sufficient free disk space in the guest
[  16.2] Converting CentOS Linux release 7.9.2009 (Core) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 107.5] Mapping filesystem data to avoid copying unused and blank areas
[ 109.4] Closing the overlay
[ 109.7] Assigning disks to buses
[ 109.7] Checking if the guest needs BIOS or UEFI to boot
[ 109.7] Setting up the destination: -o null
[ 110.8] Copying disk 1/1
█ 100% [****************************************]
[ 143.4] Creating output metadata
[ 143.4] Finishing off

Test result - Import OVA file successfully.

Test scenario-2: import the OVA file to RHV

# virt-v2v -i ova protect_appliance.ova -o rhv -os 10.73.196.77:/home/data --bridge ovirtmgmt -on protect_appliance -v -x |& tee>virt_v2v_ova.log
█ 100% [****************************************]

Test result:
2.1 virt-v2v command finished successfully.
2.2 Can't find the VM 'protect_appliance' on RHV Webadmin.
The debug log called: virt_v2v_ova.log

@rjones, could you have me have a look at the test result of scenario-2, thanks?

Created attachment 1871466 [details]
Debug log virt_v2v_ova.log for test scenario-2

(In reply to zhoujunqin from comment #14)

> 
> Test scenario-2: import the OVA file to RHV
> 
> # virt-v2v -i ova protect_appliance.ova -o rhv -os 10.73.196.77:/home/data
> --bridge ovirtmgmt -on protect_appliance -v -x |& tee>virt_v2v_ova.log
> █ 100% [****************************************]
> 
> Test result:
> 2.1 virt-v2v command finished successfully.
> 2.2 Can't find the VM 'protect_appliance' on RHV Webadmin.
> The debug log called: virt_v2v_ova.log
> 
> @rjones, could you have me have a look at the test result of scenario-2,
> thanks?

Sorry for your inconvenience, the usage here '-o rhv' is not right here, it should use an export_domain as a target.
And we have an existing Bug 1953286 that tracked my test scenario-2 issue.

I retest test scenario-2 with '-o rhv-upload' option and passed the test, thanks.

# virt-v2v -i ova protect_appliance.ova -o rhv-upload -of qcow2 -oc https://10.73.196.73/ovirt-engine/api -op /home/juzhou/rhvpass -os data_nfs --bridge ovirtmgmt -oo rhv-direct=true
[   0.0] Setting up the source: -i ova protect_appliance.ova
virt-v2v: warning: making OVA directory public readable to work around 
libvirt bug https://bugzilla.redhat.com/1045069
[   4.5] Opening the source
[   8.8] Inspecting the source
[  13.6] Checking for sufficient free disk space in the guest
[  13.6] Converting CentOS Linux release 7.9.2009 (Core) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 104.2] Mapping filesystem data to avoid copying unused and blank areas
[ 106.2] Closing the overlay
[ 106.5] Assigning disks to buses
[ 106.5] Checking if the guest needs BIOS or UEFI to boot
[ 106.5] Setting up the destination: -o rhv-upload -oc https://10.73.196.73/ovirt-engine/api -os data_nfs
[ 118.2] Copying disk 1/1
█ 100% [****************************************]
[ 200.6] Creating output metadata
[ 212.7] Finishing off

Test result: Converting the OVA file to RHV successful, and VM 'PROTECT_Appliance' boots up successfully(Can't do additional checkpoints since I don't know the password of the user).

Yes that looks correct, thanks for testing.

In order to easily cover the bug scenario in our automation job in the future, 
I created another OVA file.

The steps to create OVA file are as follows:

1. Operation on vsphere6.7, then navigate to a virtual machine or vApp, and from the Actions menu, select Template > Export OVF Template.

2. In the Name field, enter the name of the template, such as 'ova_bug2069768'.

3. Create a user with a space existing in the name on V2V conversion server.
# useradd space\ user --badname

4. Scp the ovf-related files to the home path of the new user and generate the OVA file.

$ ll ova_bug2069768/
total 4526964
-rw-r--r--. 1 space user space user 2317782016 Apr 14 09:12 ova_bug2069768-1.vmdk
-rw-r--r--. 1 space user space user       8684 Apr 14 09:12 ova_bug2069768-2.nvram
-rw-r--r--. 1 space user space user        286 Apr 14 09:12 ova_bug2069768.mf
-rw-r--r--. 1 space user space user       6526 Apr 14 09:12 ova_bug2069768.ovf


$ tar -cvf ova_bug2069768.ova ova_bug2069768-1.vmdk ova_bug2069768-2.nvram ova_bug2069768.ovf 

$ tar tRvf ova_bug2069768.ova
block 0: -rw-r--r-- space user/space user 2317782016 2022-04-14 09:12 ova_bug2069768-1.vmdk
block 4526919: -rw-r--r-- space user/space user       8684 2022-04-14 09:12 ova_bug2069768-2.nvram
block 4526937: -rw-r--r-- space user/space user       6526 2022-04-14 09:12 ova_bug2069768.ovf
block 4526951: ** Block of NULs **

There is a space in the user/group name.

*******************************************************************************************************
Test: Convert the OVA file to RHV.

Reproduce the bug with version: virt-v2v-2.0.1-1.el9.x86_64

# virt-v2v -i ova  /home/space\ user/ova_bug2069768/ova_bug2069768.ova -o rhv-upload -of qcow2 -oc https://$rhv_engine/ovirt-engine/api -op /home/rhvpass -os data_nfs --bridge ovirtmgmt -oo rhv-direct=true
[   0.0] Setting up the source: -i ova /home/space user/ova_bug2069768/ova_bug2069768.ova
virt-v2v: warning: making OVA directory public readable to work around 
libvirt bug https://bugzilla.redhat.com/1045069
virt-v2v: error: file ‘ova_bug2069768-1.vmdk’ not found in the ova

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

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



Verify the bug with version: virt-v2v-2.0.3-1.el9.x86_64

# virt-v2v -i ova  /home/space\ user/ova_bug2069768/ova_bug2069768.ova -o rhv-upload -of qcow2 -oc https://10.73.196.73/ovirt-engine/api -op /home/rhvpass -os data_nfs --bridge ovirtmgmt -oo rhv-direct=true
[   0.7] Setting up the source: -i ova /home/space user/ova_bug2069768/ova_bug2069768.ova
virt-v2v: warning: making OVA directory public readable to work around 
libvirt bug https://bugzilla.redhat.com/1045069
[   1.8] Opening the source
[   6.9] Inspecting the source
[   9.2] Checking for sufficient free disk space in the guest
[   9.2] Converting Red Hat Enterprise Linux 9.0 Beta (Plow) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  59.7] Mapping filesystem data to avoid copying unused and blank areas
[  60.3] Closing the overlay
[  60.5] Assigning disks to buses
[  60.5] Checking if the guest needs BIOS or UEFI to boot
[  60.5] Setting up the destination: -o rhv-upload -oc https://$rhv_engine/ovirt-engine/api -os data_nfs
[  72.5] Copying disk 1/1
█ 100% [****************************************]
[ 119.4] Creating output metadata
[ 127.3] Finishing off

Test result:
I: Conversion finished successfully.
II: The VM in RHV webadmin passed all checkpoints.

So I move the bug from ON_QA to VERIFIED status, thanks.

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 (Low: virt-v2v security, 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/RHSA-2022:7968