Description of problem: when trying to use virt-v2v with cloud forms ova as input i have faced the following error: [root@localhost ~]# virt-v2v -x -v -i ova /root/cfme-rhevm-5.3-40.x86_64.rhevm.ova -o rhev -os 192.168.122.1:/usr/share/nfs/data2 --network rhevm virt-v2v: libguestfs 1.28.5 (x86_64) [ 0.0] Opening the source -i ova /root/cfme-rhevm-5.3-40.x86_64.rhevm.ova virt-v2v: error: /root/cfme-rhevm-5.3-40.x86_64.rhevm.ova: unsupported file format file cfme-rhevm-5.3-40.x86_64.rhevm.ova cfme-rhevm-5.3-40.x86_64.rhevm.ova: gzip compressed data, was "/tmp/koji/tasks/4667/8234667/output_image/tmpyJ4mqK/ova", last modified: Wed Nov 12 19:19:04 2014, max compression Reply - Reply to All - Forward - More Actions If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Version-Release number of selected component (if applicable): virt-v2v-1.28.5-1.fc21.x86_64 How reproducible: always Steps to Reproduce: mentioned above Actual results: Expected results: Additional info:
Although this bug isn't fixed yet, I've added the following commits to RHEL 7.2 as groundwork: 3c582cfb8d62013a935953e919c79009452254f9 8049474636d1a56cb259af6e527fb6b0a42e43e1
I took a more critical look at this bug today and I don't see why we want to use virt-v2v here. The input is already targeted to RHEV + KVM. According to the OVF it was created _by_ RHEV-M 4.6.0.163. The disk image is of RHEL 6.6 and it already has virtio drivers, including virtio drivers in the initramfs, so it should just boot. You shouldn't run virt-v2v on guests which are already KVM. [I know that RHEV lacks or lacked a way to import guests, but that is/was a RHEV bug, and using virt-v2v as a way to workaround that bug never was a good idea, and is explicitly prevented in the latest version.] In addition the CFME ".ova" file isn't OVA at all. The format has nothing to do with the OVA spec. It's just a dump of a RHEV storage domain. For the above reasons, I am closing this bug.