From what I have observed, OVA import seems to have two modes:

If the OVA is a 'foreign' format, the ova file needs to be converted and that 
conversion effort is then logged into /var/log/vdsm/import on the oVirt node 
where in import runs. Import failures are then mostly an issue with the 
inability to either open the OVA file itself for writing or perhaps another 
temorary file just besides. Under the assumption that the conversion was 
running under the UID/GID of vdsm, I ensured that write permissions on file and 
directory were given to vdsm:kvm and at that point the conversion ran fine and 
spewed plenty of logging output to a file on that path.

Now when the OVA came from an oVirt export, that log file doesn't seem to get 
created, at least I never saw something appear there, even after the import had 
successfully finished, as per GUI.

But those OVA re-imports where completely buggy, mostly because the export 
files seem to be defect, an error I just reported in another post.

For you with a VMware export, things might look more bright, once you sort out 
access rights and potentially fs capacity, as the conversion might require 
enough temporary space for two copies of the VM, since it seems to only be put 
into oVirt storage, after the conversion.
Users mailing list --
To unsubscribe send an email to
Privacy Statement:
oVirt Code of Conduct:
List Archives:

Reply via email to