[libvirt] Question about parallel migration connections
jfehlig at suse.com
Fri Jan 10 14:22:00 UTC 2020
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.
> 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 ...'.
> 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.
More information about the libvir-list