[Kimchi-devel] [RFC] Guest cloning

[Yu Xin Huo]

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.
>
>
>     Description
>
> 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:
>
>   * name: the new guest will have an automatically generated name. We
>     can append "-clone<n>" to the original guest's name, where <n> is
>     related to the number of clones created from that guest. For
>     example, cloning a guest named "myfedora" will create a new guest
>     named "myfedora-clone1"; if another clone for that same guest is
>     requested, it will be named "myfedora-clone2".
>   * uuid: the new guest will have an automatically generated UUID. We
>     can create a random UUID for every cloned guest.
>   * devices/interface/mac: the new guest will have an automatically
>     generated MAC address for every network interface. We can create
>     random MAC addresses for every cloned guest.
>   * devices/disk: the new guest will have copies of the original
>     guest's disks. Depending on the storage pool type of each disk, a
>     different procedure may be used to copy that disk:
>
>       * DIR, NFS, Logical: the disk file will be copied to a new file
>         with a modified name (e.g. "disk.img" -> "disk-clone1.img") on
>         the same storage pool.
>       * SCSI, iSCSI: the volume data will be copied as a new disk file
>         on the storage pool "default".
>
>
>     REST API
>
> Only one new REST command will be added.
>
>
>         Syntax
>
> POST /vms//<vm-name>//clone
>
>
>         Parameters:
>
> None.
>
>
>         Return:
>
> 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.
>
>
>     Discussion
>
> 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
> "hardlink".
>
> Any feedback is welcome!
>
> Best regards,
> Crístian.
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20141010/565e3878/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iiecgdec.png
Type: image/png
Size: 25735 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20141010/565e3878/attachment.png>