QEMU NBD protocol support
=========================

QEMU supports the NBD protocol, and has an internal NBD client (see
``block/nbd.c``), an internal NBD server (see ``blockdev-nbd.c``), and an
external NBD server tool (see ``qemu-nbd.c``). The common code is placed
in ``nbd/*``.

The NBD protocol is specified here:
https://github.com/NetworkBlockDevice/nbd/blob/master/doc/proto.md

The following paragraphs describe some specific properties of NBD
protocol realization in QEMU.

Metadata namespaces
-------------------

QEMU supports the ``base:allocation`` metadata context as defined in the
NBD protocol specification, and also defines an additional metadata
namespace ``qemu``.

``qemu`` namespace
------------------

The ``qemu`` namespace currently contains two available metadata context
types.  The first is related to exposing the contents of a dirty
bitmap alongside the associated disk contents.  That metadata context
is named with the following form::

    qemu:dirty-bitmap:<dirty-bitmap-export-name>

Each dirty-bitmap metadata context defines only one flag for extents
in reply for ``NBD_CMD_BLOCK_STATUS``:

bit 0:
  ``NBD_STATE_DIRTY``, set when the extent is "dirty"

The second is related to exposing the source of various extents within
the image, with a single metadata context named::

    qemu:allocation-depth

In the allocation depth context, the entire 32-bit value represents a
depth of which layer in a thin-provisioned backing chain provided the
data (0 for unallocated, 1 for the active layer, 2 for the first
backing layer, and so forth).

For ``NBD_OPT_LIST_META_CONTEXT`` the following queries are supported
in addition to the specific ``qemu:allocation-depth`` and
``qemu:dirty-bitmap:<dirty-bitmap-export-name>``:

``qemu:``
  returns list of all available metadata contexts in the namespace
``qemu:dirty-bitmap:``
  returns list of all available dirty-bitmap metadata contexts

Features by version
-------------------

The following list documents which qemu version first implemented
various features (both as a server exposing the feature, and as a
client taking advantage of the feature when present), to make it
easier to plan for cross-version interoperability.  Note that in
several cases, the initial release containing a feature may require
additional patches from the corresponding stable branch to fix bugs in
the operation of that feature.

2.6
  ``NBD_OPT_STARTTLS`` with TLS X.509 Certificates
2.8
  ``NBD_CMD_WRITE_ZEROES``
2.10
  ``NBD_OPT_GO``, ``NBD_INFO_BLOCK``
2.11
  ``NBD_OPT_STRUCTURED_REPLY``
2.12
  ``NBD_CMD_BLOCK_STATUS`` for ``base:allocation``
3.0
  ``NBD_OPT_STARTTLS`` with TLS Pre-Shared Keys (PSK),
  ``NBD_CMD_BLOCK_STATUS`` for ``qemu:dirty-bitmap:``, ``NBD_CMD_CACHE``
4.2
  ``NBD_FLAG_CAN_MULTI_CONN`` for shareable read-only exports,
  ``NBD_CMD_FLAG_FAST_ZERO``
5.2
  ``NBD_CMD_BLOCK_STATUS`` for ``qemu:allocation-depth``
7.1
  ``NBD_FLAG_CAN_MULTI_CONN`` for shareable writable exports
8.2
  ``NBD_OPT_EXTENDED_HEADERS``, ``NBD_FLAG_BLOCK_STATUS_PAYLOAD``