Re: [Qemu-block] [PATCH] nbd: Advertise multi-conn for shared read-only connections

[Nir Soffer]

On Mon, Aug 19, 2019 at 9:04 PM Eric Blake <address@hidden> wrote:

On 8/17/19 8:31 PM, Nir Soffer wrote:
>>> Also, for qemu-nbd, shouldn't we allow -e only together with -r ?
>>
>> I'm reluctant to; it might break whatever existing user is okay exposing
>> it (although such users are questionable, so maybe we can argue they
>> were already broken).  Maybe it's time to start a deprecation cycle?
>>
>
> man qemu-nbd (on Centos 7.6) says:
>
>        -e, --shared=num
>            Allow up to num clients to share the device (default 1)
>
> I see that in qemu-img 4.1 there is a note about consistency with writers:
>
>        -e, --shared=num
>            Allow up to num clients to share the device (default 1). Safe
> for readers, but for now, consistency is not guaranteed between multiple
> writers.
> But it is not clear what are the consistency guarantees.
>
> Supporting multiple writers is important. oVirt is giving the user a URL
> (since 4.3), and the user
> can use multiple connections using the same URL, each having a connection
> to the same qemu-nbd
> socket. I know that some backup vendors tried to use multiple connections
> to speed up backups, and
> they may try to do this also for restore.
>
> An interesting use case would be using multiple connections on client side
> to write in parallel to
> same image, when every client is writing different ranges.

Good to know.

>
> Do we have real issue in qemu-nbd serving multiple clients writing to
> different parts of
> the same image?

If a server advertises multi-conn on a writable image, then clients have
stronger guarantees about behavior on what happens with flush on one
client vs. write in another, to the point that you can make some better
assumptions about image consistency, including what one client will read
after another has written.  But as long as multiple clients only ever
access distinct portions of the disk, then multi-conn is not important
to that client (whether for reading or for writing).

Thanks for making this clear. I think we need to document this in oVirt,

so users will be careful about using multiple connections.

 

So it sounds like I have no reason to deprecate qemu-nbd -e 2, even for
writable images.

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