Re: [Kimchi-devel] Kimchi migration within peers

on 2014/10/23 22:38, Leonardo Augusto Guimarães Garcia wrote: > lagarcia(a)br.ibm.comn 10/23/2014 08:43 AM, simonjin wrote: >> 在 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. > I agree there is no way to migrate to oVirt/OpenStack. However, from our > perspective, this should not matter. > > As you said on your proposal "Source libvirtd/client should be able to > connect destination libvirtd.". So, the only thing that should matter is > whether we have a libvirt running on the other side or not. This is what > we need to check (and I think libvirt API checks this for us and return > an error if it doesn't find a libvirt running on the destination). From > a migration perspective, it doesn't matter if the destination is running > Kimchi, oVirt, OpenStack or any other management tool. We should only > check if libvirt is running and, if it is running and the migration is > successful, we are good. > > On the Kimchi UI, we will, of course, have an easy way to select a > Kimchi peer and migrate to it if Federation is on and other peers have > discovered but we need to give the option to the user, IMO, to select an > arbitrary IP where they know libvirt is running to migrate the VM to > that host. > > Best regards, > > Leonardo Garcia In my opinion, it would be very nice to support migrate to any host with libvirtd. This makes Kimchi easily integrated into other projects. I think we can implement migration targeting at libvirt level. Kimchi peers discovery are just to provide a host list for user's convenience. We can also make Kimchi check and configure libvirt to be able to accept migration connection. _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel