Re: [Kimchi-devel] Kimchi migration within peers

在 2014年10月22日 20:28, Aline Manera 写道: > > 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? > Migration should be only between kimchi peers, there is no way to migrate to ovirt/openstack host via kimchi API.

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