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

[Daniel P. Berrange]

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...

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

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)


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


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


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.  

  - Document the scenarios I just outlined and give some mre
    guidance to app developers/administrators about the tradeoff
    between each scenario

Regards,
Daniel