----- Original Message ----- > From: "Nir Soffer" <[email protected]> > To: "Allon Mureinik" <[email protected]> > Cc: "Christopher Pereira" <[email protected]>, [email protected], "Federico > Simoncelli" <[email protected]> > Sent: Friday, May 29, 2015 5:37:16 PM > Subject: Re: [ovirt-devel] Unable to import templates > > ----- Original Message ----- > > From: "Allon Mureinik" <[email protected]> > > To: "Christopher Pereira" <[email protected]> > > Cc: [email protected] > > Sent: Thursday, May 28, 2015 3:31:36 PM > > Subject: Re: [ovirt-devel] Unable to import templates > > > > ----- Original Message ----- > > > From: "Christopher Pereira" <[email protected]> > > > To: [email protected] > > > 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 > > In general, we prefer to do all image operations using qemu-img. If an > optimization is needed, better do it in qemu-img, improving all users. > > But if you send a patch for this and back it up with benchmark results, > proving that this make a significant improvement, I think it should be > easy to get it merged.
And don't forget that you'll have to implement the progress report for "cp" as well. -- Federico _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
