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