<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 10/10/2014 06:34 AM, Yu Xin Huo
wrote:<br>
</div>
<blockquote cite="mid:5437A82A.4060408@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">When user click on clone button
below, a request is sent to server.<br>
Server should pre-check to see whether all relevant storage
pools have enough space to copy vm volumes.<br>
<img src="cid:part1.03030608.00090501@linux.vnet.ibm.com" alt=""><br>
<br>
If the pre-check fail, response a message indicate the vm
volumes that need re-assign a pool. Then UI popup a dialog
below.<br>
Once user selected the pool and click 'Clone' button, then
re-send the request with [{disk1: Pool-A},{disk2:
Pool-B},{disk3: Pool-C}]<br>
<img src="cid:part2.05060007.09090808@linux.vnet.ibm.com" alt=""><br>
</div>
</blockquote>
<br>
There may be a time between user clicks on "Clone" until get a
response from pool capacity.<br>
In that time, what will be shown to user? A loading icon in
somewhere?<br>
<br>
<blockquote cite="mid:5437A82A.4060408@linux.vnet.ibm.com"
type="cite">
<div class="moz-cite-prefix"> <br>
Once the cloning process is triggered.<br>
<img src="cid:part3.08040702.03050206@linux.vnet.ibm.com" alt=""><br>
<br>
</div>
</blockquote>
<br>
I think we can display a new VM box with an loading icon on
"Livetitle" with "Clone in progress..." or something like it.<br>
I don't think we need to display the progress messages to user. At
least I would just care about new VM cloned.<br>
<br>
<blockquote cite="mid:5437A82A.4060408@linux.vnet.ibm.com"
type="cite">
<div class="moz-cite-prefix"> 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=windows-1252">
<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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a moz-do-not-send="true" 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>
<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>