QEMU NBD protocol support — QEMU documentation

# 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`