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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list