projects / qemu.git / blame
| Commit | Line | Data |
|---|---|---|
| 3229a835 VSO |
1 | Qemu supports the NBD protocol, and has an internal NBD client (see |
| 2 | block/nbd.c), an internal NBD server (see blockdev-nbd.c), and an | |
| 3 | external NBD server tool (see qemu-nbd.c). The common code is placed | |
| 4 | in nbd/*. | |
| 5 | ||
| 6 | The NBD protocol is specified here: | |
| 7 | https://github.com/NetworkBlockDevice/nbd/blob/master/doc/proto.md | |
| 8 | ||
| 9 | The following paragraphs describe some specific properties of NBD | |
| 10 | protocol realization in Qemu. | |
| 11 | ||
| 12 | = Metadata namespaces = | |
| 13 | ||
| 14 | Qemu supports the "base:allocation" metadata context as defined in the | |
| 15 | NBD protocol specification, and also defines an additional metadata | |
| 16 | namespace "qemu". | |
| 17 | ||
| 3229a835 VSO |
18 | == "qemu" namespace == |
| 19 | ||
| 20 | The "qemu" namespace currently contains only one type of context, | |
| 21 | related to exposing the contents of a dirty bitmap alongside the | |
| 22 | associated disk contents. That context has the following form: | |
| 23 | ||
| 24 | qemu:dirty-bitmap:<dirty-bitmap-export-name> | |
| 25 | ||
| 26 | Each dirty-bitmap metadata context defines only one flag for extents | |
| 27 | in reply for NBD_CMD_BLOCK_STATUS: | |
| 28 | ||
| 29 | bit 0: NBD_STATE_DIRTY, means that the extent is "dirty" | |
| 30 | ||
| 31 | For NBD_OPT_LIST_META_CONTEXT the following queries are supported | |
| 32 | in addition to "qemu:dirty-bitmap:<dirty-bitmap-export-name>": | |
| 33 | ||
| 34 | * "qemu:" - returns list of all available metadata contexts in the | |
| 35 | namespace. | |
| 36 | * "qemu:dirty-bitmap:" - returns list of all available dirty-bitmap | |
| 37 | metadata contexts. | |
| ba2d3b3a EB |
38 | |
| 39 | = Features by version = | |
| 40 | ||
| 41 | The following list documents which qemu version first implemented | |
| 42 | various features (both as a server exposing the feature, and as a | |
| 43 | client taking advantage of the feature when present), to make it | |
| 44 | easier to plan for cross-version interoperability. Note that in | |
| 45 | several cases, the initial release containing a feature may require | |
| 46 | additional patches from the corresponding stable branch to fix bugs in | |
| 47 | the operation of that feature. | |
| 48 | ||
| 49 | * 2.6: NBD_OPT_STARTTLS with TLS X.509 Certificates | |
| 50 | * 2.8: NBD_CMD_WRITE_ZEROES | |
| 51 | * 2.10: NBD_OPT_GO, NBD_INFO_BLOCK | |
| 52 | * 2.11: NBD_OPT_STRUCTURED_REPLY | |
| 53 | * 2.12: NBD_CMD_BLOCK_STATUS for "base:allocation" | |
| 54 | * 3.0: NBD_OPT_STARTTLS with TLS Pre-Shared Keys (PSK), | |
| 55 | NBD_CMD_BLOCK_STATUS for "qemu:dirty-bitmap:", NBD_CMD_CACHE |