[Kimchi-devel] Kimchi migration within peers

[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?

>
>>
>> -Simon
>>>> -  do finish if migration successful.
>>>>
>>>>
>>>> Comments are welcome!
>>>> -- 
>>>> Yun Tong Jin, Simon
>>>> Linux Technology Center, Open Virtualization project
>>>> IBM Systems & Technology Group
>>>> jinyt at cn.ibm.com, Phone: 824549654
>>>
>>
>>
>> -- 
>> Yun Tong Jin, Simon
>> Linux Technology Center, Open Virtualization project
>> IBM Systems & Technology Group
>> jinyt at cn.ibm.com, Phone: 824549654
>
>
>
> _______________________________________________
> 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/20141022/e73ed2a3/attachment.html>