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@cn.ibm.com, Phone: 824549654 

-- 
Yun Tong Jin, Simon
Linux Technology Center, Open Virtualization project
IBM Systems & Technology Group
jinyt@cn.ibm.com, Phone: 824549654