[Kimchi-devel] Kimchi migration within peers
Aline Manera
alinefm at linux.vnet.ibm.com
Fri Oct 31 13:41:32 UTC 2014
On 10/31/2014 07:18 AM, simonjin wrote:
> 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.
>
Sorry, but I didn't understand the LDAP implication on it.
Kimchi authentication does not impact the system authentication.
So the migration API should be something like:
POST /vms/my-vm/migrate {host: my-dest-host, username:
dest-host-username, password: my-password}
username and password as the values needed to SSH to the destination host.
It will not depend on Kimchi authentication.
> 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/a99f660b/attachment.html>
More information about the Kimchi-devel
mailing list