Libguestfs - May 2021 - [PATCH libnbd] copy: Always allow multiple connections

Actually no, I had to revert this.

https://gitlab.com/nbdkit/libnbd/-/commit/fb42056929e9177e0de2603e2f430a8111ae7a5f

I added a test:

https://gitlab.com/nbdkit/libnbd/-/commit/23b41ad0a2a6d6582a8e643e42960d2e3c72e53e

However the test deadlocks when we try to open multiple connections to
qemu-nbd (with your patch).  As best I can tell this is because of
qemu's file locking.  qemu-nbd doesn't seem to support the -U option
found in qemu-img, but even if it did I don't think it would be a good
idea to tell users that they have to use it.

I think this needs to be fixed in qemu-nbd itself.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

On Thu, May 27, 2021 at 1:49 PM Richard W.M. Jones <rjones at redhat.com>
wrote:
>
>
> Actually no, I had to revert this.
>
>
https://gitlab.com/nbdkit/libnbd/-/commit/fb42056929e9177e0de2603e2f430a8111ae7a5f
>
> I added a test:
>
>
https://gitlab.com/nbdkit/libnbd/-/commit/23b41ad0a2a6d6582a8e643e42960d2e3c72e53e
>
> However the test deadlocks when we try to open multiple connections to
> qemu-nbd (with your patch).  As best I can tell this is because of
> qemu's file locking.  qemu-nbd doesn't seem to support the -U
option
> found in qemu-img, but even if it did I don't think it would be a good
> idea to tell users that they have to use it.
When using qemu-nbd you need to specify --shared=4 on both source and
destination.

Current nbdcopy depends on the server supporting multiple connections,
so we try to
open the additional connections in the main thread. If the server
supports only one
connection (--shared=4 not specified), this will deadlock.

One way to fix this is to open the extra connection in the worker
threads. If the server
does not support more then one connection, only one worker can make
progress, and
the other will just block on nbd_connect(). When the first worker
finishes all the work,
the rest of the workers will connect and find that they have no work
to do and exit.
> I think this needs to be fixed in qemu-nbd itself.
I don't think we can change qemu-nbd behavior at this point.

Nir