Here is the explanation, I think:
root     12319 12313 15 16:59 pts/0    00:00:56 qemu-img convert -O qcow2 
/dev/loop0 
/rhev/data-center/mnt/glusterSD/192.168.0.91:_vmstore/9d1b8774-c5dc-46a8-bfa2-6a6db5851195/images/3be7c1bb-377c-4d5e-b4f6-1a6574b8a52b/845cdd93-def8-4d84-9a08-f8c991f89fe3

This is where the image is entering from the OVA source and gets written on the 
Gluster.

I consistently chose one of the computer cluster nodes, because they have the 
bigger CPUs and it also happened to have the OVA file locally, so the network 
wouldn't have to carry source and sink traffic...

But unless I use one of the nodes that actually have bricks in the Gluster, I 
get this strange silent failure.

First thing I did notice is that during the import dialog, more details about 
the engines are actually visible (disk and network details), before I actually 
launch the import, although Cockpit doesn't seem to care.

I then theorized, that the compute nodes won't actually mount the Gluster file 
system on /rhev, so the target would be missing... but they do in fact...

I'll not go into further details but take away this lesson:

"If you want to import an OVA files to a Gluster farm, you must use a node 
which is part of the gluster to do the import on."

Ah, yes, the import succeeded and oVirt immediately chose the nicely bigger 
Xeon-D node to run the VM...

Now I just need to find out how to twiddle OVA export files from oVirt to make 
them digestable for VMware and VirtualBox...
_______________________________________________
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: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QVN6BMIYATKZF6K3EO7HU5FRJD4LBIA2/

Reply via email to