aboutsummaryrefslogtreecommitdiff
path: root/qapi
diff options
context:
space:
mode:
authorEric Blake <eblake@redhat.com>2020-10-27 00:05:55 -0500
committerEric Blake <eblake@redhat.com>2020-10-30 15:22:00 -0500
commitdbc7b01492371e4a54b92d2b6d968f9b863cc794 (patch)
tree24812091f95b86d03192a23bec70e21d9a5b74eb /qapi
parent71719cd57fc02ddfd91a4a3ca3f469bfb4d221bc (diff)
nbd: Add 'qemu-nbd -A' to expose allocation depth
Allow the server to expose an additional metacontext to be requested by savvy clients. qemu-nbd adds a new option -A to expose the qemu:allocation-depth metacontext through NBD_CMD_BLOCK_STATUS; this can also be set via QMP when using block-export-add. qemu as client is hacked into viewing the key aspects of this new context by abusing the already-experimental x-dirty-bitmap option to collapse all depths greater than 2, which results in a tri-state value visible in the output of 'qemu-img map --output=json' (yes, that means x-dirty-bitmap is now a bit of a misnomer, but I didn't feel like renaming it as it would introduce a needless break of back-compat, even though we make no compat guarantees with x- members): unallocated (depth 0) => "zero":false, "data":true local (depth 1) => "zero":false, "data":false backing (depth 2+) => "zero":true, "data":true libnbd as client is probably a nicer way to get at the information without having to decipher such hacks in qemu as client. ;) Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20201027050556.269064-11-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Diffstat (limited to 'qapi')
-rw-r--r--qapi/block-core.json7
-rw-r--r--qapi/block-export.json7
2 files changed, 11 insertions, 3 deletions
diff --git a/qapi/block-core.json b/qapi/block-core.json
index e00fc27b5e..1b8b4156b4 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -3905,9 +3905,12 @@
#
# @tls-creds: TLS credentials ID
#
-# @x-dirty-bitmap: A "qemu:dirty-bitmap:NAME" string to query in place of
+# @x-dirty-bitmap: A metadata context name such as "qemu:dirty-bitmap:NAME"
+# or "qemu:allocation-depth" to query in place of the
# traditional "base:allocation" block status (see
-# NBD_OPT_LIST_META_CONTEXT in the NBD protocol) (since 3.0)
+# NBD_OPT_LIST_META_CONTEXT in the NBD protocol; and
+# yes, naming this option x-context would have made
+# more sense) (since 3.0)
#
# @reconnect-delay: On an unexpected disconnect, the nbd client tries to
# connect again until succeeding or encountering a serious
diff --git a/qapi/block-export.json b/qapi/block-export.json
index c4125f4d21..a9f488f99c 100644
--- a/qapi/block-export.json
+++ b/qapi/block-export.json
@@ -90,11 +90,16 @@
# the metadata context name "qemu:dirty-bitmap:BITMAP" to inspect
# each bitmap.
#
+# @allocation-depth: Also export the allocation depth map for @device, so
+# the NBD client can use NBD_OPT_SET_META_CONTEXT with
+# the metadata context name "qemu:allocation-depth" to
+# inspect allocation details. (since 5.2)
+#
# Since: 5.2
##
{ 'struct': 'BlockExportOptionsNbd',
'base': 'BlockExportOptionsNbdBase',
- 'data': { '*bitmaps': ['str'] } }
+ 'data': { '*bitmaps': ['str'], '*allocation-depth': 'bool' } }
##
# @BlockExportOptionsVhostUserBlk: