[libvirt] Question about parallel migration connections

[Jim Fehlig]

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 ...'.

Regards,
Jim

> 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
>