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

[Eric Blake]

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