<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.6.6">
</HEAD>
<BODY>
Hi everyone,<BR>
<BR>
I'm presenting here my proposal for the feature "Guest cloning" which<BR>
is expected to be implemented for Kimchi 1.4.
<H2>
Description
</H2>
Cloning a guest means creating a new guest with a copy of the settings<BR>
and data of the original guest. All data described by its XML will be<BR>
copied completely, with the following exceptions:
<UL>
<LI><TT>name</TT>: 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".
<LI><TT>uuid</TT>: the new guest will have an automatically generated UUID. We can create a random UUID for every cloned guest.
<LI><TT>devices/interface/mac</TT>: the new guest will have an automatically generated MAC address for every network interface. We can create random MAC addresses for every cloned guest.
<LI><TT>devices/disk</TT>: 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:
<BLOCKQUOTE>
<LI>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.
<LI>SCSI, iSCSI: the volume data will be copied as a new disk file on the storage pool "default".
</BLOCKQUOTE>
</UL>
<H2>
REST API
</H2>
Only one new REST command will be added.
<H4>
Syntax
</H4>
<TT>POST /vms/</TT><TT><I><vm-name></I></TT><TT>/clone</TT>
<H4>
Parameters:
</H4>
None.
<H4>
Return:
</H4>
An asynchronous Task with "<TT>target_uri</TT>" containing "<TT>/vms/<</TT><TT><I>new-vm-name</I></TT><TT>></TT>".<BR>
As expected with any Task, the cloning process can be tracked by<BR>
checking the corresponding task's status.
<H2>
Discussion
</H2>
I think the most challenging part of this feature is how to deal with<BR>
different types of disks while not prompting the user with any input.<BR>
There are a lot of possibilities and a lot of things that can go wrong<BR>
during the disks copy but we still need to do whatever is easier for<BR>
the user. For example, do we really have to create the new disks in<BR>
the same storage pool as the original disk's? If that's not possible<BR>
(e.g. not available space), should we create them in another pool with<BR>
available space? Should we ask any input from the user (e.g. "Would you<BR>
like to create the new disk on the same storage pool or on a different<BR>
one?")? What about the *SCSI pool types, is it OK to copy the volume<BR>
data to a different storage pool (i.e. "default") like I'm proposing<BR>
here? I couldn't think of a way to add a new volume in an existing pool<BR>
of those types. How about making the *SCSI volumes shareable between<BR>
the original and the new VMs? I don't like that approach because then<BR>
both VMs will use the same disk, whatever is changed in one VM is also<BR>
changed in the other one, and that's not a clone for me, that's a<BR>
"hardlink".<BR>
<BR>
Any feedback is welcome!<BR>
<BR>
Best regards,<BR>
Crístian.
</BODY>
</HTML>