[ovirt-devel] Unable to import templates

[Allon Mureinik]

----- Original Message -----
> From: "Christopher Pereira" <kripper at imatronix.cl>
> To: devel at ovirt.org
> Sent: Tuesday, May 26, 2015 1:44:16 AM
> Subject: [ovirt-devel] Unable to import templates
> 
> Hi,
> 
> A user was unable to import a VM template from a gluster export storage
> because of various reasons, and since I'm afraid this could hit many
> users (losing many days waiting for import tasks to...fail) I would like
> to share the issues and some ideas with you:
> 
> 1) Slowness:
> 
> FYI, working with sparse files on GlusterFS mounts will be very slow
> until https://bugzilla.redhat.com/show_bug.cgi?id=1220173 is implemented.
> Maybe the same applies also to other network file-systems.
> 
> 2) Engine Task timeout:
> 
> The last times the user tried to import this template (using nightly
> builds), the task was apparently deleted by Engine because of timeout
> while the qemu-img process continued running (and consuming resources).
> I'm not sure, but I believe the tasks are deleted by Engine after 4 or 5
> days no matter if the qemu-img process is still running (!?).
> Thus, slow import tasks will never finish.
> Can someone please confirm?
> Maybe we can improve something here to support long import tasks.
Sounds like a bug.
Could you please report it with all the logs, etc. attached?


> 
> 3) Wrong SPM:
> 
> If $SRC is on host-1, $DST on host-2 and SPM is host-3, the image will
> be unnecessarily crossing host-3 and kill the cluster performance.
> I guess Engine should choose automatically the appropriate SPM host
> depending on the tasks (host-1 or host-2 in this case).
> But it seems like oVirt doesn't currently support changing the SPM when
> there are running tasks, based on the fact that the user gets a warning
> when trying to do it manually.
Moving around SPM is WAY too dangerous to do per operation.
Looking forward, this should be part of the non-SPM architecture, probably after 3.6.0.

> 
> 4) Convert Optimization:
> 
> I see oVirt is running:
> /usr/bin/qemu-img convert -t none -T none -f raw $SRC -O raw $DST
> 
> In this case, $SRC is in raw format and there are no backing chains.
> 
> Shouldn't we do a simple 'cp --sparse=always' instead of a 'qemu-img
> convert' in this case?
> I guess qemu-img should be doing this optimization for us, but maybe
> this raw-to-raw conversion use case is just to silly and will not be
> considered by qemu-img maintainers.
Definitely worth checking

> 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>