After applying the OVA export patch, that ensured disk content was actually written ino the OVA image, I have been able to transfer *.ova VMs between two oVirt clusters. There are still problems that I will report once I have fully tested what's going on, but in the mean-time for all those, who want to be able to move VMs not only in the direction of oVirt (seems well tested), but also the other way (e.g. local desktop use, or even a vSphere farm) an OVA export could be a life saver--if it worked. I have tried importing oVirt exported VMs (which correctly imported and ran on a second oVirt host) both on VMware workstation 15.5.6 and VirtualBox 6.1.12 running on a Windows 2019 host without success. I've also tried untaring the *.ova into the component *.ovf + image file, but the issue seems to be with the XML description which has both imports fail pretty much instantly, before they even read the disk image file. From what I can tell, the XML created by qemu-img looks just fine, the error messages emitted by both products are very sparse and seem misleading. E.g. VirtualBox complains "Empty element ResourceType under Item element, line 1.", while I see all <Item> well constructed with a ResourceType in every one of them. VMware Workstation is completely useless in terms of log-file-diagnostics: It reports an invalid value for the "populatedSize" for the "Disk", but doesn't log that to the ovftool.log. I am pretty sure the error is in the inconsistent interpretation of this section, where the AllocationUnits, capacity and populatedSize leave some room for misinterpretation: -<DiskSection> <Info>List of Virtual Disks</Info> <Disk ovf:cinder_volume_type="" ovf:disk_storage_type="IMAGE" ovf:description="Auto-generated for Export To OVA" ovf:wipe-after-delete="false" ovf:disk-description="" ovf:disk-alias="oeight_Disk1" ovf:pass-discard="true" ovf:boot="true" ovf:disk-interface="VirtIO_SCSI" ovf:volume-type="Sparse" ovf:volume-format="RAW" ovf:format="http://www.vmware.com/specifications/vmdk.html#sparse" ovf:fileRef="974ad04f-d9bb-4881-aad2-c1d5404200ef" ovf:parentRef="" ovf:populatedSize="536953094144" ovf:capacityAllocationUnits="byte * 2^30" ovf:capacity="500" ovf:diskId="02b8d976-7e42-44e7-8e24-06f974f1c3ea"/> </DiskSection> I am trying to import the *.ova files on a Windows host and the sparsity get typically lost on the scp file transfer, too. Yes, this most likely isn't an oVirt bug, qemu-img is maintained elsewhere and the problem to me looks more on the receiver side. But have you tried it? Can you imagine it being important, too?