[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Selecting meta context when calling NBD_CMD_BLOCK_STATUS

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


> 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: 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.

Reply to: