<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I am also thinking to add a centralized
area in header to hold all asynchronous tasks.<br>
<img src="cid:part1.02030809.01030808@linux.vnet.ibm.com" alt=""><br>
<br>
On 10/3/2014 2:05 AM, Crístian Viana wrote:<br>
</div>
<blockquote cite="mid:1412273105.8887.43.camel@kitkat.br.ibm.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="GENERATOR" content="GtkHTML/4.6.6">
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>
<li><tt>uuid</tt>: the new guest will have an automatically
generated UUID. We can create a random UUID for every cloned
guest. </li>
<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>
<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>
<li>SCSI, iSCSI: the volume data will be copied as a new
disk file on the storage pool "default". </li>
</blockquote>
</li>
</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.
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>