<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 10/31/2014 07:18 AM, simonjin wrote:<br>
</div>
<blockquote cite="mid:545353ED.6010804@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
As migration over TCP required libvirt config modification on
destination, <br>
the workaround is migrate via ssh which only required ssh
connection to destination.<br>
<br>
option 1:<br>
manually do ssh authentication with sth like ssh-copy-id -i
~/.ssh/id_rsa.pub root@remote<br>
option 2:<br>
Require user/password of destination server and kimchi will do the
ssh authentication with:<br>
sshpass -p password ssh-copy-id -i ~/.ssh/id_rsa.pub root@remote<br>
<br>
Issue: <br>
With kimchi authentication via LAPD, the user/password won't exist
on destination server.<br>
<br>
</blockquote>
<br>
Sorry, but I didn't understand the LDAP implication on it.<br>
<br>
Kimchi authentication does not impact the system authentication.<br>
<br>
So the migration API should be something like:<br>
<br>
POST /vms/my-vm/migrate {host: my-dest-host, username:
dest-host-username, password: my-password}<br>
<br>
username and password as the values needed to SSH to the destination
host.<br>
It will not depend on Kimchi authentication.<br>
<br>
<blockquote cite="mid:545353ED.6010804@linux.vnet.ibm.com"
type="cite"> Any thoughts ?<br>
<br>
-Simon<br>
<br>
<div class="moz-cite-prefix">于 2014年10月28日 18:03, simonjin 写道:<br>
</div>
<blockquote cite="mid:544F69FF.10401@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
The problem is how to do authentication between two peers, <br>
which requires libvirtd conf modification on destination and
SASL setup <br>
<br>
From libvirtd.conf:<br>
<i># Listen for unencrypted TCP connections on the public TCP/IP
port.</i><i><br>
</i><i># NB, must pass the --listen flag to the libvirtd process
for this to</i><i><br>
</i><i># have any effect.</i><i><br>
</i><i>#</i><i><br>
</i><i># Using the TCP socket requires SASL authentication by
default. Only</i><i><br>
</i><i># SASL mechanisms which support data encryption are
allowed. This is</i><i><br>
</i><i># DIGEST_MD5 and GSSAPI (Kerberos5)</i><i><br>
</i><i>#</i><i><br>
</i><i># This is disabled by default, uncomment this to enable
it.</i><i><br>
</i><i>listen_tcp = 1</i><br>
<br>
-Simon<br>
<br>
<div class="moz-cite-prefix">在 2014年10月24日 15:28, Zhou Zheng
Sheng 写道:<br>
</div>
<blockquote cite="mid:5449FF92.1020407@linux.vnet.ibm.com"
type="cite">
<pre wrap="">on 2014/10/23 22:38, Leonardo Augusto Guimarães Garcia wrote:
</pre>
<blockquote type="cite">
<pre wrap=""><a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:lagarcia@br.ibm.comn">lagarcia@br.ibm.comn</a> 10/23/2014 08:43 AM, simonjin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">在 2014年10月22日 20:28, Aline Manera 写道:
</pre>
<blockquote type="cite">
<pre wrap="">On 10/22/2014 10:20 AM, Aline Manera wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 10/22/2014 07:24 AM, simonjin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 10/22/2014 01:48 AM, Aline Manera wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 10/20/2014 12:50 AM, simonjin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
I'm presenting here my proposal for the feature "Guest migration"
which
is expected to be implemented for Kimchi 1.4.
Description
Migrate guest vm within peer/host discovered by Kimchi peers
using openSLP.
In the first stage 1, only do migration will be supported,
in stage2, migrateCancel and migrateMonitor will be supported.
*Migration Mode: *
1. Support libvirt tunnelled transport managed by direct migration.
2. Only support Live migration mode.
3. Only support migration over TCP
*Migration Capability Check*
- Source libvirtd/client should be able to connect destination
libvirtd.
- CPU architectures compare(X86 vs PPC).
- No PCI device passthrough.
- In a shared storage pool and the pool can be access/write by
destination.
REST API
Only one new REST command will be added in stage 1.
Syntax
POST /vms//<vm-name>//migrate
</pre>
</blockquote>
<pre wrap="">You will have a data object informing the destination host
POST /vms/<vm-name>/migrate {host: ...}
</pre>
</blockquote>
<pre wrap="">ok, the json data will be {host:ip, user:username, passwd:password}
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> Parameters:
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">in config.py.in:
('migration_destination_timeout', '21600',
'Maximum time the destination waits for the migration
to finish.
21600 should be enough since all the peers will be in
the same LAN'),
('migration_max_bandwidth', 'unlimited',
'default in libvirt is unlimited'),
('migration_downtime', '500',
'Maxmium allowed downtime for live migration in
milliseconds '
'(anything below 100ms is ignored) if you do not care
about '
'liveness of migration, set to a very high value,
such as '
'600000.'),
</pre>
</blockquote>
<pre wrap="">I don't think we need to allow user edits those values so there is
no need to add them to config.py.in
</pre>
</blockquote>
<pre wrap="">It's better to put them in kimchi.conf to allow user to edit just
in case the migration failed due to them.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> Return:
An asynchronous Task with "target_uri" containing
"/vms/</new-vm-name/>".
As expected with any Task, the cloning process can be tracked by
checking the corresponding task's status.
*Do_migration step:*
- migration source check .
</pre>
</blockquote>
<pre wrap="">What kind of verification will be done?
Storage pool and network? Guest permission settings?
</pre>
</blockquote>
<pre wrap="">will do *Migration Capability Check *described above*.
*
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">- connect migration destination, guest vm config/params transfer
and setup.
</pre>
</blockquote>
<pre wrap="">How will it be done?
>From libvirt doc, I can see different types of migration, which
one is the best solution for Kimchi?
For reference: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://libvirt.org/migration.html">http://libvirt.org/migration.html</a>
</pre>
</blockquote>
<pre wrap="">It will be tunneled + P2P migration,
so the API will be like:
do_migrate = dom.migrateToURI2(dest, muri, None,
libvirt.VIR_MIGRATE_LIVE |
libvirt.VIR_MIGRATE_PEER2PEER |
libvirt.VIR_MIGRATE_TUNNELLED |
libvirt.VIR_MIGRATE_ABORT_ON_ERROR,
None, maxbandwidth)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">- migration source prepare.
- do actually migration.
</pre>
</blockquote>
<pre wrap="">Does libvirt python API have native support for that?
</pre>
</blockquote>
<pre wrap="">Will wrapper the native libvirt python API and put it in a task.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">- recover if failed.
</pre>
</blockquote>
<pre wrap="">Probably, on fail, some leftovers will be on destination server.
How will you do the clean up?
</pre>
</blockquote>
<pre wrap="">Will destroy remote vm instance on destination and resume source vm
is being paused.
</pre>
<blockquote type="cite">
<pre wrap="">Will it be a communication between the Kimchi servers?
</pre>
</blockquote>
<pre wrap="">the migration communication will be between to libvirtd.
</pre>
<blockquote type="cite">
<pre wrap="">What about if the destination server does not have a Kimchi setup?
</pre>
</blockquote>
<pre wrap="">the destination server is discovered by kimchi, which will guaranty
it has a kimchi setup.
</pre>
</blockquote>
<pre wrap="">So can not I migrate my guest to a new server without Kimchi?
</pre>
</blockquote>
<pre wrap="">What about I am migrating from Kimchi to ovirt/openstack?
</pre>
</blockquote>
<pre wrap="">Migration should be only between kimchi peers,
there is no way to migrate to ovirt/openstack host via kimchi API.
</pre>
</blockquote>
<pre wrap="">I agree there is no way to migrate to oVirt/OpenStack. However, from our
perspective, this should not matter.
As you said on your proposal "Source libvirtd/client should be able to
connect destination libvirtd.". So, the only thing that should matter is
whether we have a libvirt running on the other side or not. This is what
we need to check (and I think libvirt API checks this for us and return
an error if it doesn't find a libvirt running on the destination). From
a migration perspective, it doesn't matter if the destination is running
Kimchi, oVirt, OpenStack or any other management tool. We should only
check if libvirt is running and, if it is running and the migration is
successful, we are good.
On the Kimchi UI, we will, of course, have an easy way to select a
Kimchi peer and migrate to it if Federation is on and other peers have
discovered but we need to give the option to the user, IMO, to select an
arbitrary IP where they know libvirt is running to migrate the VM to
that host.
Best regards,
Leonardo Garcia
</pre>
</blockquote>
<pre wrap="">In my opinion, it would be very nice to support migrate to any host with
libvirtd. This makes Kimchi easily integrated into other projects. I
think we can implement migration targeting at libvirt level. Kimchi
peers discovery are just to provide a host list for user's convenience.
We can also make Kimchi check and configure libvirt to be able to accept
migration connection.
_______________________________________________
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>
</blockquote>
<br>
</body>
</html>