[Kimchi-devel] Kimchi migration within peers

[simonjin]

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.

-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/71f1ee6e/attachment.html>