[Kimchi-devel] Kimchi migration within peers

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 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.'), 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 . - connect migration destination, guest vm config/params transfer and setup. - migration source prepare. - do actually migration. - recover if failed. - do finish if migration successful. Comments are welcome! -- Yun Tong Jin, Simon Linux Technology Center, Open Virtualization project IBM Systems & Technology Group jinyt(a)cn.ibm.com, Phone: 824549654