[libvirt] [PATCH 0/9] Support new peer-2-peer migration mode & public API

[Daniel Veillard]

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 at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/