Re: [Kimchi-devel] Kimchi migration within 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: >>> >>> 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. > > 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(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 > > > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel