Re: [Kimchi-devel] Kimchi migration within peers

The problem is how to do authentication between two peers, which requires libvirtd conf modification on destination and SASL setup From libvirtd.conf: /# Listen for unencrypted TCP connections on the public TCP/IP port.// //# NB, must pass the --listen flag to the libvirtd process for this to// //# have any effect.// //#// //# Using the TCP socket requires SASL authentication by default. Only// //# SASL mechanisms which support data encryption are allowed. This is// //# DIGEST_MD5 and GSSAPI (Kerberos5)// //#// //# This is disabled by default, uncomment this to enable it.// //listen_tcp = 1/ -Simon ? 2014?10?24? 15:28, Zhou Zheng Sheng ??: > 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 _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel