Re: Selecting meta context when calling NBD_CMD_BLOCK_STATUS

[Nir Soffer]

On Thu, Dec 26, 2019 at 4:52 PM Richard W.M. Jones <address@hidden> wrote:
>
> On Thu, Dec 26, 2019 at 04:29:03PM +0200, Nir Soffer wrote:
> > Currently client need to use NBD_OPT_SET_META_CONTEXT during handshake to
> > select the meta context it wants to get in NBD_CMD_BLOCK_STATUS.
> >
> > This means that if you want to provide the option to get both
> > "base:allocation" and
> > "qemu:dirty-bitmap:x" using the same NBD client connection, you must
> > pay for getting
> > both during NBD_CMD_BLOCK_STATUS even if the user of the NBD client is not 
> > going
> > to use both.
> >
> > Or, you can use new client connection for getting meta context not
> > that the current
> > client did not select, which require server that supports multiple
> > connections, and new
> > handshake. This seems to be more complicated than needed.
>
> What's the problem with opening another connection?  Could it be
> you're confusing this with the "multi-conn" capability which is
> different?

For qemu-nbd, this requires --shared=N with N > 1.

Let's say you don't want to allow multiple connections because of the
weak consistency offered by qemu-nbd in this case when used in
read-write mode. If you use --shared=1, you will not be able to use
another client to report dirty bitmap. If you use --shared=2, you must
allow now multiple connections, and if the first client is using multiple
connections, the second client may fail to connect.

In the of qemu during incremental backup we always use read-only
connection, so there is no consistency issue, and using another client
connection is easy.

But generally this is too complicated and feels wrong to me.

> > This complicates existing clients:
> > - qemu-img can return either "base:allocation" or
> > "qemu:dirty-bitmap:x" using complex
> >   undocumentde configuration
> > - ovirt-imageio is using dirty flag in the client to enable both
> > "base:allocation" and
> >   "qemu:dirty-bitmap:x", so we can provide merged extents reporting
> > both allocation
> >   status and "dirtiness" for every extent.
> >
> > Should we extend NBD_CMD_BLOCK_STATUS so we can specify list of meta context
> > at the time of the call?
> >
> > Looking at command structure, I don't think it could be extended. We
> > need to specify
> > list of 32 bit context ids, so we need something like:
> >
> > 32 bits, length of payload (N * 4)
> > 32 bits, contex id 1
> > ...
> > 32 bits, context id N
> >
> > But the length field of a BLOCK_STATUS command is already used to
> > specify the range
> > of the reply.
> >
> > So maybe add a new handshake flag, NBD_OPT_EXTENDED_COMMAND. If set during
> > handshake, and NBD_FLAG_EXTENDED is set, a command will support
> > additional payload
> > like the list of context ids.
> >
> > So a BLOCK_STATUS command will look like:
> >
> > C: 32 bits, NBD_REQUEST_MAGIC)
> > C: 16 bits, NBD_FLAG_EXTENDED
> > C: 16 bits, NBD_CMD_BLOCK_STATUS
> > C: 64 bits, 42
> > C: 64 bits, 0
> > C: 32 bits, 1073741824
> > C: 32 bits: 4
> > C: 32 bit: 1
> >
> > With this the server reply will be only for context id 1.
> >
> > What do you think?
> >
> > Nir
>
> --
> 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
>