[Kimchi-devel] Kimchi migration within peers

[Aline Manera]

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: ...}

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

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

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

> -  migration source prepare.
> -  do actually migration.

Does libvirt python API have native support for that?

> -  recover if failed.

Probably, on fail, some leftovers will be on destination server. How 
will you do the clean up?
Will it be a communication between the Kimchi servers? What about if the 
destination server does not have a Kimchi setup?

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

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