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

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