On Thu, Jan 09, 2020 at 11:04:19PM +0000, Jim Fehlig wrote: > Are they supported with tunneled migration? The feature seems limited to native > migration, in which case I can send a patch prohibiting parallel migration > connections with the tunnel. Native migration should be preferred over tunneled migration these days. The tunneled migration feature was primarily a workaround for the lack of TLS support in QEMU, in order to leverage libvirtd's TLS connection. QEMU has support for TLS directly in its native migration protocol these days. That should be preserved as it provides a better performing data channel than tunnelling. This will especially be seen with parallel migration. Even if libvirt enabled parallel migration with tunnelling, libvirtd does all I/O in a single thread, so you wouldn't see any performance benefit from it, especially when TLS is used. This is actually true whether you've got a single QEMU with multiple TCP connections for migration, or multiple QEMU's migrating concurrently. Both situations will be limited by libvirt's single thread for I/O. With QEMU's native TLS support and parallell migration you'll be able to max out performance of many CPUs to maximise data throughput. The only real interesting benefit of tunnelled migration that remains is the fact that everything happens over a single TCP port, so there is less to open in the firewall. IMHO this is not compelling enough to offset the serious performance downsides of tunnelling, now that QEMJU has native TLS support. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
