[Kimchi-devel] Kimchi migration within peers
simonjin
simonjin at linux.vnet.ibm.com
Tue Oct 28 10:03:43 UTC 2014
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20141028/4456dbcb/attachment.html>
More information about the Kimchi-devel
mailing list