Description of problem: Add solution for the bug in virt-v2v-input-vmware man page or skip check mf file during ova conversion Version-Release number of selected component (if applicable): virt-v2v-2.3.4-2.el9.x86_64 How reproducible: 100% Steps to Reproduce: 1.Prepare a ova folder which is freshly exported from VMware, v2v can convert guest from ova successfully this time # virt-v2v -i ova esx8.0-win2022-x86_64-efi -o null [ 0.2] Setting up the source: -i ova esx8.0-win2022-x86_64-efi virt-v2v: warning: making OVA directory public readable to work around libvirt bug https://bugzilla.redhat.com/1045069 [ 9.0] Opening the source [ 14.1] Inspecting the source [ 20.8] Checking for sufficient free disk space in the guest [ 20.8] Converting Windows Server 2022 Standard to run on KVM virt-v2v: This guest has virtio drivers installed. [ 37.4] Mapping filesystem data to avoid copying unused and blank areas [ 39.8] Closing the overlay [ 40.1] Assigning disks to buses [ 40.1] Checking if the guest needs BIOS or UEFI to boot virt-v2v: This guest requires UEFI on the target to boot. [ 40.1] Setting up the destination: -o null [ 41.1] Copying disk 1/1 █ 100% [****************************************] [ 155.1] Creating output metadata [ 155.1] Finishing off 2. Modify the guest name of ovf file and then convert guest from ova by v2v again # vi esx8.0-win2022-x86_64-efi/esx8.0-win2022-x86_64-efi.ovf # virt-v2v -i ova esx8.0-win2022-x86_64-efi -o null [ 0.2] Setting up the source: -i ova esx8.0-win2022-x86_64-efi virt-v2v: warning: making OVA directory public readable to work around libvirt bug https://bugzilla.redhat.com/1045069 virt-v2v: error: -i ova: corrupt OVA: checksum of disk /home/esx8.0-win2022-x86_64-efi/esx8.0-win2022-x86_64-efi.ovf does not match manifest (actual = 8eaa91b039e4ac127938da250af330a380c6bfda0b6e08aa1616e7226c8e489c, expected = sha256) If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] 3. Modify the sha256 of ovf file in the mf file according to the v2v error and then convert guest from ova by v2v again # cat esx8.0-win2022-x86_64-efi/esx8.0-win2022-x86_64-efi.mf SHA256(esx8.0-win2022-x86_64-efi.ovf)= 745fecf99b08fdb9854bf0d849a625b5ff048b0fc78a373c97b6a46c9040698e SHA256(esx8.0-win2022-x86_64-efi-1.vmdk)= 984d50dbc2467deabda1f005cad34aea70898a98fd3573275c9c148ea16ea465 SHA256(esx8.0-win2022-x86_64-efi-2.nvram)= b472a13995eea256587616e36c19c163201af0d8c1c418334519bf19d6606231 # sed -i 's/745fecf99b08fdb9854bf0d849a625b5ff048b0fc78a373c97b6a46c9040698e/8eaa91b039e4ac127938da250af330a380c6bfda0b6e08aa1616e7226c8e489c/g' esx8.0-win2022-x86_64-efi/esx8.0-win2022-x86_64-efi.mf # virt-v2v -i ova esx8.0-win2022-x86_64-efi -o null [ 0.2] Setting up the source: -i ova esx8.0-win2022-x86_64-efi virt-v2v: warning: making OVA directory public readable to work around libvirt bug https://bugzilla.redhat.com/1045069 [ 9.0] Opening the source [ 14.0] Inspecting the source [ 20.9] Checking for sufficient free disk space in the guest [ 20.9] Converting Windows Server 2022 Standard to run on KVM virt-v2v: This guest has virtio drivers installed. [ 37.7] Mapping filesystem data to avoid copying unused and blank areas [ 40.3] Closing the overlay [ 40.6] Assigning disks to buses [ 40.6] Checking if the guest needs BIOS or UEFI to boot virt-v2v: This guest requires UEFI on the target to boot. [ 40.6] Setting up the destination: -o null [ 41.6] Copying disk 1/1 █ 100% [****************************************] [ 153.1] Creating output metadata [ 153.1] Finishing off Actual results: Many customers encounter the bug, such as case03325510 and comment with time 'May 18, 2023, 01:16:16 AM GMT+8' in case03502740, customers don't know the workaround for the problem and can't find info about the error in virt-v2v-input-vmware man page Expected results: As above description Additional info:
So we discussed this over email. The basic problem is that someone has unpacked the OVA and modified the .ovf file inside, which can be a reasonable thing to do in some circumstances, eg the rename the guest or remove unwanted devices. However the .mf (metafile) which contains a checksum of the .ovf file was not modified. As a result when the OVA is loaded, virt-v2v correctly identifies that the .ovf file does not match the checksum, ie. it appears to have been corrupted, and virt-v2v also correctly rejects the conversion. The possible solutions to this include: - Document the issue explaining how to fix it (remove the line from .mf), or - When comparing the .ovf file to the checksum, if the checksum doesn't match but the .ovf file is still well-formed XML, then only issue a warning but continue with the conversion. This issue did affect at least two customers in the past, although both resolved it with help from support.