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.
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
List Archives: 

Reply via email to