2018-06-09 23:17:58 +08:00
|
|
|
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 only one type of context,
|
|
|
|
|
related to exposing the contents of a dirty bitmap alongside the
|
|
|
|
|
associated disk contents. That context has 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, means that the extent is "dirty"
|
|
|
|
|
|
|
|
|
|
For NBD_OPT_LIST_META_CONTEXT the following queries are supported
|
|
|
|
|
in addition to "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.
|
2018-12-15 21:53:04 +08:00
|
|
|
|
|
|
|
|
= 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
|
nbd: Advertise multi-conn for shared read-only connections
The NBD specification defines NBD_FLAG_CAN_MULTI_CONN, which can be
advertised when the server promises cache consistency between
simultaneous clients (basically, rules that determine what FUA and
flush from one client are able to guarantee for reads from another
client). When we don't permit simultaneous clients (such as qemu-nbd
without -e), the bit makes no sense; and for writable images, we
probably have a lot more work before we can declare that actions from
one client are cache-consistent with actions from another. But for
read-only images, where flush isn't changing any data, we might as
well advertise multi-conn support. What's more, advertisement of the
bit makes it easier for clients to determine if 'qemu-nbd -e' was in
use, where a second connection will succeed rather than hang until the
first client goes away.
This patch affects qemu as server in advertising the bit. We may want
to consider patches to qemu as client to attempt parallel connections
for higher throughput by spreading the load over those connections
when a server advertises multi-conn, but for now sticking to one
connection per nbd:// BDS is okay.
See also: https://bugzilla.redhat.com/1708300
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20190815185024.7010-1-eblake@redhat.com>
[eblake: tweak blockdev-nbd.c to not request shared when writable,
fix iotest 233]
Reviewed-by: John Snow <jsnow@redhat.com>
2019-08-16 02:50:24 +08:00
|
|
|
* 4.2: NBD_FLAG_CAN_MULTI_CONN for sharable read-only exports
|