[Kimchi-devel] [RFC] Guest cloning

[Aline Manera]

On 10/03/2014 10:28 AM, Brent Baude wrote:
> At one point Adam had really suggested we look at how guests are defined
> and changed.  In particular, straight copies of XML and or straight
> edits of XML could lead (after time) to the XML digressing into
> something libvirt might not understand at some point.
>
> To prevent this sort of problem, we thought that each time a guest is
> edited, the XML is created entirely anew but of course using the same
> values.  This has the distinct advantage of making future additions of
> options easier to integrate.  It is also the exact basis I think would
> be appropriate for any sort of cloning and dovetails nicely into your
> proposal.  About a month ago I had a working version of this in draft
> form.

> Would anyone be interested in reviewing it and or adding to it prior to
> implementing the clone function?  If so, ping me on IRC and I'll get you
> a copy of the patch.

Please, sent it to ML as RFC so we all can discuss on it.

> Brent
>
>
>
> On Thu, 2014-10-02 at 15:05 -0300, 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
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel