Libguestfs - May 2021 - [PATCH libnbd 3/3] copy: Update nbdcopy(1) about multiple connections

I want to see what Eric has to say about whether we can or should
change qemu-nbd.

There's a small typo in this patch:
> @@ -216,23 +215,13 @@ pipe, or a socket, or if you use the
I<--synchronous> option, then
>  nbdcopy works in synchronous mode with no parallelism, and nothing
>  else in this section applies.
>  
> -The I<--connections=N> option controls NBD multi-conn (see
> -L<libnbd(3)/Multi-conn>), opening up to N connections to the NBD
> +The I<--connections=N> option open up to N connections to the NBD
s/open/opens/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

On Thu, May 27, 2021 at 02:07:19PM +0100, Richard W.M. Jones
wrote:
> I want to see what Eric has to say about whether we can or should
> change qemu-nbd.
Changing the default to allow multiple writers may risky; I'm worried
we may be stuck with always having to opt-in to it.

On the other hand, if qemu-nbd advertises multi-conn only when
--shared=N for N>1, we'd have a nice witness for when we can use
multi-conn (but only after qemu 6.1 or downstream backports of this
as-yet unwritten patch).

Other ideas:

Add an NBD_OPT extension to allow a client to inform the server of its
intent to perform non-overlapping parallel I/O.  If the server
understands the new option, it can then proceed to allow additional
connections (that is, make qemu-nbd dynamically turn on --shared=N
based on a new-enough client requesting upload mode).  Obviously
wouldn't work until qemu 6.1 or downstream backports of the new feature.

Add an NBD_OPT extension to allow a client to learn from the server
how many connections it actually accepts (supporting a number > 1 even
without multi-conn is viable).  If the server answers, then use that
many connections; if not, then stick to 1 connection unless multi-conn
is set.  Again, something that won't work out of the box until qemu
6.1 or downstream backports of the new feature.

At any rate, looks like I need to accelerate my patches to have
qemu-nbd advertise multi-conn for --shared=N writeable servers (where
qemu itself should already be cache-consistent because it has proper
serialization of any overlapping requests, regardless of which client
is making the request).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org