Re: [Kimchi-devel] Kimchi migration within peers

As migration over TCP required libvirt config modification on destination, the workaround is migrate via ssh which only required ssh connection to destination. option 1: manually do ssh authentication with sth like ssh-copy-id -i ~/.ssh/id_rsa.pub root@remote option 2: Require user/password of destination server and kimchi will do the ssh authentication with: sshpass -p password ssh-copy-id -i ~/.ssh/id_rsa.pub root@remote Issue: With kimchi authentication via LAPD, the user/password won't exist on destination server.

Any thoughts ? -Simon 于 2014年10月28日 18:03, simonjin 写道: > 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