On Mon, Oct 05, 2009 at 12:44:47PM +0100, Daniel P. Berrange wrote: > This series is an update of > > http://www.redhat.com/archives/libvir-list/2009-September/msg00540.html > > There isn't as much functional change here as you might presume > from the number of patches. Since Chris' tunnelled migration code > is added, I thought it better to do alot of small refactoring > steps rather than munge it all in one patch. > > One particular notable change since last time is that the new > virDomainMigrateToURI method does *not* mandate use of the > new "VIR_MIGRATE_PEER2PEER" flag anymore. I will now explain > why... ah ! I won't complain, but I'm curious :) > Traditionally migration has been a 3 step process > > 1. client -> dest (prepare) > 2. client -> source (perform) > 3. client -> dest (finish) > > This is why virDomainMigrate requires the extra 'dconn' parameter > from the client app > > With the tunnelled migration / peer-to-peer migration, the extra > 'dconn' parameter is no longer required from the client, because > the source libvirt driver directly opens a connection to the > destination libvirtd daemon on the remote host. ie libvirtd is > talking to another libvirtd peer-2-peer. > > In considering the implementation of the PEER_TO_PEER flag for > the Xen and VMWare drivers though I realized that even this is not > technically neccessary, and in fact detrimental to use of libvirt > for migrating with these drivers. Both Xen and VMWare have their > own management daemon which is perfectly capable of handling the > entire process without any need for libvirtd to be involved on the > destination host. libvirt need only initiate the migration op on > the source host. If you look at the impl of Prepare/Finish ops in > the Xen driver this should be obvious, since they are pretty much > no-ops Okay > Thus we in fact have 3 possible migration processes > > * Traditional libvirt client managed > > client -> dest (prepare) > client -> source (perform) > client -> dest (finish) > > * New peer-to-peer migration (on which tunnelled mig is built) > > client -> source (perform) > source -> dest (open) > source -> dest (prepareTunnel) > source -> dest (streamSend) > source -> dest (finish) > source -> dest (close) > > * New direct migration (hypervisor managed) > > client -> source (perform) > source -> dest (whatever the HV's native migration does) > okay so we split out the last one from the P2P version > In terms of libvirt public APIs this works out as follows > > * Traditional libvirt client managed > > A hypervisor specific URI style, passed to virDomainMigrate() > with no flags set > > * New peer-to-peer migration (on which tunnelled mig is built) > > The standard libvirt URI style, passed to virDomainMigrate() > or virDomainMigrateToURI() with VIR_DOMAIN_MIGRATE_PEER2PEER > flag set. > > The virDomainMigrateToURI() method is better since it avoids > the unneccessary burden on the client of connecting to the > remote libvirtd. > > * New direct migration (hypervisor managed) > > A hypervisor specific URI style, passed to virDomainMigrateToURI() > with no flags set Okay understood, makes sense. > The QEMU driver can't support the latter, since it has no native > management daemon - it requires libvirtd's help. Xen and VMWare, > and probably VirtualBox can support this just fine. > > > This is good for flexibility of usage in terms of authentication > too, since each of these 3 modes has different characteristics > > * Traditional libvirt client managed > > client -> source libvirtd auth > client -> dest libvirtd auth > possible hypervisor -> hypervisor auth > > * New peer-to-peer migration, without tunnelling > > client -> source libvirtd auth > source -> dest libvirtd auth > possible hypervisor -> hypervisor auth > > * New peer-to-peer migration, without tunnelling > > client -> source libvirtd auth > source -> dest libvirtd auth > > * New direct migration (hypervisor managed) > > client -> source libvirtd auth > possible hypervisor -> hypervisor auth > > > NB, 'client -> source libvirtd auth' is essentially no-op > if initiating migration from the source host directly in > all these cases. > > With with the combination of the two virDomainMigrate and > virDomainMigrateToURI methods, and the VIR_MIGRATE_PEER2PEER > flag, I believe we're well placed to cover all the main > deployment/auth scenarios for migration in all hypervisors > without imposing extra auth burden ourselves as we did in > the past We need some documentation for all those options, people already get lost when there is only one command for an action, but if you can have 3 ways and multiple auth schemes it gets scary :-) > > Further things that need to be done though: > > - Xen could easily support PEER2PEER and TUNNELLED flags > > - Add a VIR_MIGRATE_SECURE flag, to indicate that the app > only wants the migration to be performed if the HV can > guarentee the data channel is secure. good point ! > - Document the scenarios I just outlined and give some mre > guidance to app developers/administrators about the tradeoff > between each scenario Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list