[libvirt] [RFC] Should libvirt be a proxy for migration data

[Daniel P. Berrange]

On Tue, Aug 16, 2011 at 11:53:04PM +0200, Jiri Denemark wrote:
> Hi all,
> 
> Currently when we start a non-tunneled migration, data go straight from
> source qemu to destination qemu. This is nice in that there is no additional
> overhead but it also has several disadvantages. If the communication between
> source and destination qemu breaks, we only get unexpected error message from
> qemu with no glue about what happened. Another issue is that if qemu cannot
> send migration data, we cannot cancel the migration because migrate_cancel
> blocks until all buffers with migration data queued up for transmission are
> written into the socket.
> 
> That said, I think we should act as a proxy between source and destination
> qemu so that we can detect and report normal errors (such as connection reset
> by peer) and cancel migration at any time. Since we have virNetSocket and we
> already use that for connecting to destination qemu, we should use it for
> proxying migration data as well. This approach also has some disadvantages,
> e.g., a single libvirt thread instead of several qemu processes will now send
> migration data from all domains that are being migrated. However, I feel like
> the gain is bigger than the downside. And we already do the same for tunneled
> migration anyway.
> 
> Any objections?

Adding libvirt into the mix introduces extra data copies on both the
source and destination libvirt. This is non-trivial extra overhead
when you are migrating guests that have multiple-GB of RAM and have
very heavy workloads.  These already push the boundaries of what is
possible todo with QEMU having a direct TCP connection. So I don't
think we should go down the route of making libvirt do copies itself
by default.

Ideally, I'd actually like QEMU to gain direct TLS/x509/SASL support
for migration, so you can do secure migration without tunnelling
over libvirtd.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|