<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 10/14/2014 12:15 AM, Aline Manera wrote:
<blockquote cite="mid:543BFA90.9090206@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 10/10/2014 07:25 AM, Yu Xin Huo
wrote:<br>
</div>
<blockquote cite="mid:5437B401.1050500@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">I am also thinking to add a
centralized area in header to hold all asynchronous tasks.<br>
</div>
</blockquote>
<br>
Hrm... Tasks are an internal concept (from development view). The
user doesn't know what they are.<br>
<br>
</blockquote>
It'd be good to have this feature to let user know what's going on
in the kimchi <br>
and even more it'd be better to have a progress bar(UI) for each
under task like guest clone/migrate.<br>
<br>
-Simon <br>
<blockquote cite="mid:543BFA90.9090206@linux.vnet.ibm.com"
type="cite">
<blockquote cite="mid:5437B401.1050500@linux.vnet.ibm.com"
type="cite">
<div class="moz-cite-prefix"> <img
src="cid:part1.03000008.03050501@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=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 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>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
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>
<br>
<pre class="moz-signature" cols="72">--
Yun Tong Jin, Simon
Linux Technology Center, Open Virtualization project
IBM Systems & Technology Group
<a class="moz-txt-link-abbreviated" href="mailto:jinyt@cn.ibm.com">jinyt@cn.ibm.com</a>, Phone: 824549654 </pre>
</body>
</html>