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.