Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Oracle Xen OVA files contain randomly non-standard OVF which virt-v2v does not support. The first symptom of this is the following error: virt-v2v: warning: could not parse ovf:Name from OVF document This happens because Oracle used the wrong xmlns (they appear to have copy and pasted the wrong URI). Fixing that results in further problems: virt-v2v: error: error parsing disk fileRef Version-Release number of selected component (if applicable): libguestfs 1.39.11 How reproducible: 100% Steps to Reproduce: 1. virt-v2v -i ova package.ova -o null Additional info: See attached minimized OVA file.
Created attachment 1500565 [details] package.ova OVA file demonstrating the problem. Note that the Windows image inside the disk is phony.
Same here, testing a vm from Oracle VirtualBox $ virt-v2v -v -x -i ova WorkshopVM.ova -o null virt-v2v: libguestfs 1.40.1fedora=29,release=2.fc29,libvirt (x86_64) libvirt version: 4.7.0 [ 0,0] Opening the source -i ova WorkshopVM.ova libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: trace: get_cachedir libguestfs: trace: get_cachedir = "/var/tmp" qemu-img info json:'{ "file": { "driver": "raw", "offset": 512, "size": 512, "file": { "filename": "/tmp/v2vqemuimgtst1f3357.img" } } }' >/dev/null qemu-img supports "offset" and "size" in json URLs: true libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: trace: get_backend libguestfs: trace: get_backend = "libvirt" libvirt supports "raw" driver in json URL: true tar -tf 'WorkshopVM.ova' tar -xf 'WorkshopVM.ova' -C '/var/tmp/ova.xHGbXQ' 'WorkshopMISP.ovf' 'WorkshopMISP.mf' ova: processing manifest file /var/tmp/ova.xHGbXQ/WorkshopMISP.mf virt-v2v: warning: unable to parse line from manifest file: "SHA1 (Workshop MISP-disk001.vmdk) = 4b3908100fd34a8ebe25c6798d3329d9845fb882" virt-v2v: warning: unable to parse line from manifest file: "SHA1 (Workshop MISP.ovf) = efd18b513279abdab2e979b9b43947de589523ad" virt-v2v: warning: could not parse ovf:Name from OVF document ova: testing if Workshop MISP-disk001.vmdk exists in WorkshopVM.ova ova: file exists tar tRvf 'WorkshopVM.ova' virt-v2v: error: failed to parse line returned by tar: "bloco 0: -rw-r----- vboxovf10/vbox_v6.0.8r130520 8665 2019-09-05 20:05 WorkshopMISP.ovf" rm -rf '/var/tmp/ova.xHGbXQ' rm -rf '/var/tmp/null.lgHblb' libguestfs: trace: close libguestfs: closing guestfs handle 0x563d782e1eb0 (state 0) libguestfs: trace: close libguestfs: closing guestfs handle 0x563d782d07e0 (state 0) $
@Spacial: I can see a couple of potential issues, however I need the OVA file. Can you please provide a link to it (in case it is public), or share it somehow?
(In reply to Pino Toscano from comment #3) > @Spacial: > I can see a couple of potential issues, however I need the OVA file. Can > you please provide a link to it (in case it is public), or share it somehow? Hi Pino, unfortunately I can't. I will try to create a new similar VM that gets same error and upload here.
Hello @Pino I have same issue with Mikrotik CHR OVA Appliane. It's public and available at: https://mikrotik.com/download With version Stable pointed at 6.47.4: [root@server images]# virt-v2v -v -x -i ova chr-6.47.4.ova -o null virt-v2v: libguestfs 1.38.4rhel=8,release=15.module_el8.2.0+320+13f867d7,libvirt (x86_64) libvirt version: 4.5.0 [ 0,0] Opening the source -i ova chr-6.47.4.ova libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: trace: get_cachedir libguestfs: trace: get_cachedir = "/var/tmp" qemu-img info json:'{ "file": { "driver": "raw", "offset": 512, "size": 512, "file": { "filename": "/tmp/v2vqemuimgtstb294c3.img" } } }' >/dev/null qemu-img supports "offset" and "size" in json URLs: true libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: trace: get_backend libguestfs: trace: get_backend = "libvirt" libvirt supports "raw" driver in json URL: true tar -tf 'chr-6.47.4.ova' tar -xf 'chr-6.47.4.ova' -C '/var/tmp/ova.zAOuzz' 'MikroTik_CHR_release_6.47.4.ovf' 'MikroTik_CHR_release_6.47.4.mf' libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: trace: get_backend libguestfs: trace: get_backend = "libvirt" virt-v2v: warning: making OVA directory public readable to work around libvirt bug https://bugzilla.redhat.com/1045069 chmod '-R' 'go=u,go-w' '/var/tmp/ova.zAOuzz' 'chr-6.47.4.ova' ova: processing manifest file /var/tmp/ova.zAOuzz/MikroTik_CHR_release_6.47.4.mf tar xOf 'chr-6.47.4.ova' 'MikroTik_CHR_release_6.47.4-disk1.vmdk' | sha256sum tar xOf 'chr-6.47.4.ova' 'MikroTik_CHR_release_6.47.4.ovf' | sha256sum ova: testing if MikroTik_CHR_release_6.47.4-disk1.vmdk exists in chr-6.47.4.ova ova: file exists tar tRvf 'chr-6.47.4.ova' virt-v2v: error: failed to parse line returned by tar: "bloco 0: -rw-r--r-- someone/someone 8267 2020-09-21 03:48 MikroTik_CHR_release_6.47.4.ovf" rm -rf '/var/tmp/ova.zAOuzz' libguestfs: trace: close libguestfs: closing guestfs handle 0x5564815ec450 (state 0) libguestfs: trace: close libguestfs: closing guestfs handle 0x55648159e320 (state 0) libguestfs: trace: close libguestfs: closing guestfs handle 0x55648159e730 (state 0) [root@server images]# The direct link for the image is https://download.mikrotik.com/routeros/6.47.4/chr-6.47.4.ova It's possible to continue this bug troubleshooting? Thanks, Leonardo Amaral.
@Leonardo Amaral: The issue you report seems a different one than the original bug report (and similar to what reported in comment 2), and most likely due to non-English locale. Try to run virt-v2v with an English locale, e.g.: $ LANG=C virt-v2v [etc...] This gets past the OVA opening, but then it fails later on: $ virt-v2v -i ova chr-6.47.4.ova -o null [ 0.0] Opening the source -i ova /var/tmp/chr-6.47.4.ova [ 0.2] Creating an overlay to protect the source from being modified [ 0.2] Opening the overlay [ 5.8] Inspecting the overlay virt-v2v: error: inspection could not detect the source guest (or physical machine). Assuming that you are running virt-v2v/virt-p2v on a source which is supported (and not, for example, a blank disk), then this should not happen. No root device found in this operating system image. If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] This is because libguestfs does not detect any operating system in the disk. Thus a possible starting point would be to add support for detecting this RouterOS in libguestfs. Then we'd have to add support for converting RouterOS in virt-v2v; however, from what I see it is a mini OS mostly in initramfs: ><fs> find / SHOW_LICENSE UPGRADED bin bin/bash bin/milo boot boot/initrd.rgz boot/map boot/memtest.bin boot/milo.conf boot/vmlinuz boot/vmlinuz-64 boot/vmlinuz-smp dev dev/bootdev dev/bootpart lost+found nova nova/etc nova/etc/serial rw rw/ENABLE_X86_64 rw/REBOOT rw/autorun.scr var var/pdb var/pdb/dude var/pdb/dude/image var/pdb/ipv6 var/pdb/ipv6/disabled var/pdb/routeros-x86 var/pdb/routeros-x86/image which means that there is not much that virt-v2v can do with this anyway. Considering that they offer also raw images for download, my suggestion is use those for QEMU/KVM environments, rather than trying to convert an OVA designed for VMware.
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.
Reopening because Virtualization Tools has not been discontinued.