On Thu, Apr 8, 2021 at 3:50 AM <eevans(a)digitaldatatechs.com&gt; wrote: It states no bootable disk is available. There's no option to change the format of the imported disks at the moment so they'd keep being thin-provisioned as they are within the OVA. I doubt that's the reason for the failure of those VMs to boot though - can you please share the engine.log that shows the configuration that a VM that didn't manage to boot started with?

On Thu, Apr 8, 2021 at 12:04 PM Gianluca Cecchi <gianluca.cecchi(a)gmail.com&gt; wrote: Good point. It's indeed more likely to be the reason than what I had in mind :)

The last oVirt 4.3 release contains a bug which will export OVAs with empty disks. Just do a du -h <ova-filename> to see if it contains more than the XML header and tons of zeros. Hopefully the orignal VMs are still with you because you'll need to fix the python code that does the export: It's a single line of code that needs to be added. https://bugzilla.redhat.com/show_bug.cgi?id=1813028 It's a bit of a nasty surprise, when you've relied on OVA export/import as the most primitve operation for a hypervisor, especially before a migration. While the bug was fixed for 4.4 in March or earlier, it didn't make it into the last 4.3 release... you have the source, after all. The deprecated export domain seems to work across the 4.3 to 4.4 gap, even if they are still deprecated on 4.4 and their handling is nowhere as flexible as OVA files. My understanding of the developer's opinion is that OVA is really just an import facility for all those VMware machines you want to migrate to oVirt. Nothing you'd ever want to use for anything else, especially not for the other direction. I consider the ability to export an important management VM like a IAS as an OVA and be able to run it on say a virtualbox, a potential life saver, especially when a farm got lost in a 4.3 to 4.4 migration. Not that I am planning that any longer...