Re: [libvirt] Question about parallel migration connections

On 1/10/20 2:26 AM, Daniel P. Berrangé wrote: > 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. Tunneled serves the same purpose in the xen driver. > 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. Nod. > 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 docs on parallel migration are slim. What guidance should we provide wrt selecting a reasonable number of connections for parallel migration? Should users experiment to find a number that saturates the network link used for migration? AFAICT there are currently no bounds checks on the number. E.g. there is nothing preventing 'virsh migrate --parallel --parallel-connections 1000 ...'.