[Kimchi-devel] Kimchi migration within peers

[Aline Manera]

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?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20141022/c8bab557/attachment.html>