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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel