Migration should be only between kimchi peers,
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: ok, the json data will be {host:ip, user:username, passwd:password}
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: ...}
It's better to put them in kimchi.conf to allow user to edit just in case the migration failed due to them.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
will do Migration Capability Check described above.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?
It will be tunneled + P2P migration,- 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
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)
Will wrapper the native libvirt python API and put it in a task.- migration source prepare.
- do actually migration.
Does libvirt python API have native support for that?
Will destroy remote vm instance on destination and resume source vm is being paused.- 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?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?
-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
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel