I am also thinking to add a centralized area in header to hold all asynchronous tasks.

On 10/3/2014 2:05 AM, Crístian Viana wrote:
Hi everyone,

I'm presenting here my proposal for the feature "Guest cloning" which
is expected to be implemented for Kimchi 1.4.


Cloning a guest means creating a new guest with a copy of the settings
and data of the original guest. All data described by its XML will be
copied completely, with the following exceptions:


Only one new REST command will be added.


POST /vms/<vm-name>/clone




An asynchronous Task with "target_uri" containing "/vms/<new-vm-name>".
As expected with any Task, the cloning process can be tracked by
checking the corresponding task's status.


I think the most challenging part of this feature is how to deal with
different types of disks while not prompting the user with any input.
There are a lot of possibilities and a lot of things that can go wrong
during the disks copy but we still need to do whatever is easier for
the user.  For example, do we really have to create the new disks in
the same storage pool as the original disk's? If that's not possible
(e.g. not available space), should we create them in another pool with
available space? Should we ask any input from the user (e.g. "Would you
like to create the new disk on the same storage pool or on a different
one?")? What about the *SCSI pool types, is it OK to copy the volume
data to a different storage pool (i.e. "default") like I'm proposing
here? I couldn't think of a way to add a new volume in an existing pool
of those types. How about making the *SCSI volumes shareable between
the original and the new VMs? I don't like that approach because then
both VMs will use the same disk, whatever is changed in one VM is also
changed in the other one, and that's not a clone for me, that's a

Any feedback is welcome!

Best regards,

Kimchi-devel mailing list