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