Re: [Kimchi-devel] Kimchi migration within peers

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(a)cn.ibm.com, Phone: 824549654 > -- Yun Tong Jin, Simon Linux Technology Center, Open Virtualization project IBM Systems & Technology Group jinyt(a)cn.ibm.com, Phone: 824549654