<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Eclipse can run long task in
background. 'Run in Background' is just like kimchi's async tasks.<br>
It use a centralized task manager to manage those tasks.<br>
<br>
Currently, kimchi's long tasks are distributed along with each
feature. <br>
The problem is that if the user is not waiting on the original
location, user need to assume that if no error occur, the task is
completed and he need to remember the object he is operating on.<br>
<br>
<img src="cid:part1.09090200.02020605@linux.vnet.ibm.com" alt=""><br>
<br>
<br>
On 10/14/2014 2:47 PM, simonjin wrote:<br>
</div>
<blockquote cite="mid:543CC6FB.5070605@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
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:part2.00030603.07050601@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 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>
<pre class="moz-signature" cols="72">--
Yun Tong Jin, Simon
Linux Technology Center, Open Virtualization project
IBM Systems & Technology Group
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:jinyt@cn.ibm.com">jinyt@cn.ibm.com</a>, Phone: 824549654 </pre>
</blockquote>
<br>
</body>
</html>