[Kimchi-devel] Kimchi migration within peers
simonjin
simonjin at linux.vnet.ibm.com
Fri Oct 31 09:18:37 UTC 2014
As migration over TCP required libvirt config modification on destination,
the workaround is migrate via ssh which only required ssh connection to
destination.
option 1:
manually do ssh authentication with sth like ssh-copy-id -i
~/.ssh/id_rsa.pub root at remote
option 2:
Require user/password of destination server and kimchi will do the ssh
authentication with:
sshpass -p password ssh-copy-id -i ~/.ssh/id_rsa.pub root at remote
Issue:
With kimchi authentication via LAPD, the user/password won't exist on
destination server.
Any thoughts ?
-Simon
? 2014?10?28? 18:03, simonjin ??:
> The problem is how to do authentication between two peers,
> which requires libvirtd conf modification on destination and SASL setup
>
> From libvirtd.conf:
> /# Listen for unencrypted TCP connections on the public TCP/IP port.//
> //# NB, must pass the --listen flag to the libvirtd process for this to//
> //# have any effect.//
> //#//
> //# Using the TCP socket requires SASL authentication by default. Only//
> //# SASL mechanisms which support data encryption are allowed. This is//
> //# DIGEST_MD5 and GSSAPI (Kerberos5)//
> //#//
> //# This is disabled by default, uncomment this to enable it.//
> //listen_tcp = 1/
>
> -Simon
>
> ? 2014?10?24? 15:28, Zhou Zheng Sheng ??:
>> on 2014/10/23 22:38, Leonardo Augusto Guimarães Garcia wrote:
>>> lagarcia at br.ibm.comn 10/23/2014 08:43 AM, simonjin wrote:
>>>> ? 2014?10?22? 20:28, Aline Manera ??:
>>>>> On 10/22/2014 10:20 AM, Aline Manera wrote:
>>>>>> On 10/22/2014 07:24 AM, simonjin wrote:
>>>>>>> On 10/22/2014 01:48 AM, Aline Manera wrote:
>>>>>>>> On 10/20/2014 12:50 AM, simonjin wrote:
>>>>>>>>> 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
>>>>>>>> You will have a data object informing the destination host
>>>>>>>>
>>>>>>>> POST /vms/<vm-name>/migrate {host: ...}
>>>>>>>>
>>>>>>> ok, the json data will be {host:ip, user:username, passwd:password}
>>>>>>>
>>>>>>>>> Parameters:
>>>>>>>>>
>>>>>>>>> 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.'),
>>>>>>>> I don't think we need to allow user edits those values so there is
>>>>>>>> no need to add them to config.py.in
>>>>>>>>
>>>>>>> It's better to put them in kimchi.conf to allow user to edit just
>>>>>>> in case the migration failed due to them.
>>>>>>>
>>>>>>>>> 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 .
>>>>>>>> What kind of verification will be done?
>>>>>>>> Storage pool and network? Guest permission settings?
>>>>>>>>
>>>>>>> will do *Migration Capability Check *described above*.
>>>>>>>
>>>>>>> *
>>>>>>>>> - connect migration destination, guest vm config/params transfer
>>>>>>>>> and setup.
>>>>>>>> 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:http://libvirt.org/migration.html
>>>>>>>>
>>>>>>> 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)
>>>>>>>
>>>>>>>>> - migration source prepare.
>>>>>>>>> - do actually migration.
>>>>>>>> Does libvirt python API have native support for that?
>>>>>>>>
>>>>>>> Will wrapper the native libvirt python API and put it in a task.
>>>>>>>>> - recover if failed.
>>>>>>>> Probably, on fail, some leftovers will be on destination server.
>>>>>>>> How will you do the clean up?
>>>>>>> Will destroy remote vm instance on destination and resume source vm
>>>>>>> is being paused.
>>>>>>>> Will it be a communication between the Kimchi servers?
>>>>>>> the migration communication will be between to libvirtd.
>>>>>>>> What about if the destination server does not have a Kimchi setup?
>>>>>>>>
>>>>>>> the destination server is discovered by kimchi, which will guaranty
>>>>>>> it has a kimchi setup.
>>>>>> So can not I migrate my guest to a new server without Kimchi?
>>>>> What about I am migrating from Kimchi to ovirt/openstack?
>>>>>
>>>> Migration should be only between kimchi peers,
>>>> there is no way to migrate to ovirt/openstack host via kimchi API.
>>> 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
>> 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
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20141031/a0c1fb52/attachment.html>
More information about the Kimchi-devel
mailing list