<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/20/2014 12:50 AM, simonjin wrote:<br>
</div>
<blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<div class="moz-text-html" lang="x-unicode"> Hi all,<br>
<br>
I'm presenting here my proposal for the feature "Guest
migration" which<br>
is expected to be implemented for Kimchi 1.4.
<h2> Description </h2>
Migrate guest vm within peer/host discovered by Kimchi peers
using openSLP.<br>
In the first stage 1, only do migration will be supported, <br>
in stage2, migrateCancel and migrateMonitor will be supported.<br>
<br>
<b>Migration Mode: </b><br>
1. Support libvirt tunnelled transport managed by direct
migration.<br>
2. Only support Live migration mode.<br>
3. Only support migration over TCP <br>
<br>
<b>Migration Capability Check</b><br>
- Source libvirtd/client should be able to connect destination
libvirtd.<br>
- CPU architectures compare(X86 vs PPC). <br>
- No PCI device passthrough.<br>
- In a shared storage pool and the pool can be access/write by
destination.<br>
<br>
<h2> REST API </h2>
Only one new REST command will be added in stage 1.
<h4> Syntax </h4>
<tt>POST /vms/</tt><tt><i><vm-name></i></tt><tt>/migrate</tt></div>
</blockquote>
<br>
You will have a data object informing the destination host<br>
<br>
POST /vms/<vm-name>/migrate {host: ...}<br>
<br>
<blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
type="cite">
<div class="moz-text-html" lang="x-unicode">
<h4> Parameters: </h4>
</div>
</blockquote>
<br>
<blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
type="cite">
<div class="moz-text-html" lang="x-unicode"><small>in
config.py.in: <br>
<br>
('migration_destination_timeout', '21600',<br>
'Maximum time the destination waits for the
migration to finish. <br>
21600 should be enough since all the peers will be
in the same LAN'),<br>
<br>
('migration_max_bandwidth', 'unlimited',<br>
'default in libvirt is unlimited'),<br>
<br>
('migration_downtime', '500',<br>
'Maxmium allowed downtime for live migration in
milliseconds '<br>
'(anything below 100ms is ignored) if you do not
care about '<br>
'liveness of migration, set to a very high value,
such as '<br>
'600000.'),<br>
</small></div>
</blockquote>
<br>
I don't think we need to allow user edits those values so there is
no need to add them to config.py.in<br>
<br>
<blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
type="cite">
<div class="moz-text-html" lang="x-unicode"><small> </small>
<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. <br>
<br>
<b>Do_migration step:</b><br>
- migration source check .<br>
</div>
</blockquote>
<br>
What kind of verification will be done?<br>
Storage pool and network? Guest permission settings?<br>
<br>
<blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
type="cite">
<div class="moz-text-html" lang="x-unicode"> - connect migration
destination, guest vm config/params transfer and setup.<br>
</div>
</blockquote>
<br>
How will it be done?<br>
From libvirt doc, I can see different types of migration, which one
is the best solution for Kimchi?<br>
<br>
For reference: <a class="moz-txt-link-freetext" href="http://libvirt.org/migration.html">http://libvirt.org/migration.html</a><br>
<br>
<blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
type="cite">
<div class="moz-text-html" lang="x-unicode"> - migration source
prepare.<br>
- do actually migration.<br>
</div>
</blockquote>
<br>
Does libvirt python API have native support for that?<br>
<br>
<blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
type="cite">
<div class="moz-text-html" lang="x-unicode"> - recover if failed.<br>
</div>
</blockquote>
<br>
Probably, on fail, some leftovers will be on destination server. How
will you do the clean up?<br>
Will it be a communication between the Kimchi servers? What about if
the destination server does not have a Kimchi setup?<br>
<br>
<blockquote cite="mid:54447886.6020603@linux.vnet.ibm.com"
type="cite">
<div class="moz-text-html" lang="x-unicode"> - do finish if
migration successful.<br>
<br>
<br>
Comments are welcome!<br>
</div>
<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>