[Kimchi-devel] Kimchi migration within peers

[simonjin]

在 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.

>>
>>>
>>> -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/20141023/dc5caf79/attachment.html>