Empty disks from exports that went wrong didn't help. But that's fixed now, even if I can't fully validate the OVA exports on VMware and VirtualBox. The export/import target for the *.ova files is an SSD hosted xfs file system on a pure compute Xeon D oVirt node, exported and automounted to the 3nHCI cluster, also all SSD but J5005 Atoms. As I import the OVA file, I chose the Xeon-D as the import node and the *local path* on that host for the import. Cockpit checks the OVA file, detects the machine inside, lets me select and chose it for import, potentially overriding some parameters, lets me choose the target storage volume, sets up the job... and then fails, rather siliently and with very little in terms of error reporting ("connection closed") is the best I got. Now that same process worked just fine on a single node HCI cluster (also J5005 Atom), which had me a bit stunned at first, but gave a hint as to the cause: Parts of the input job, most likely an qemu-img job, isn't run via the machine you selected in the first step and unless the path is global (e.g. external NFS), it fails. If someone from the oVirt team could check and validate or disprove this theory, that could be documented and/or added as a check to avoid people falling into the same trap. While I was testing this using a global automount path, my cluster failed me (creating and deleting VMs a bit too quickly?) and I had to struggle for a while to have it recover. While those transient ailures are truly frightening, oVirt's ability to recover from these scenarios is quite simply awsome. I guess it's really mostly miscommunication and not real failures and oVirt has lots of logic to rectify that.