2020-09-24 18:26:48 +03:00
|
|
|
# -*- Mode: Python -*-
|
|
|
|
# vim: filetype=python
|
|
|
|
|
|
|
|
##
|
|
|
|
# == Block device exports
|
|
|
|
##
|
|
|
|
|
|
|
|
{ 'include': 'sockets.json' }
|
qapi: nbd-export: allow select bitmaps by node/name pair
Hi all! Current logic of relying on search through backing chain is not
safe neither convenient.
Sometimes it leads to necessity of extra bitmap copying. Also, we are
going to add "snapshot-access" driver, to access some snapshot state
through NBD. And this driver is not formally a filter, and of course
it's not a COW format driver. So, searching through backing chain will
not work. Instead of widening the workaround of bitmap searching, let's
extend the interface so that user can select bitmap precisely.
Note, that checking for bitmap active status is not copied to the new
API, I don't see a reason for it, user should understand the risks. And
anyway, bitmap from other node is unrelated to this export being
read-only or read-write.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@openvz.org>
Message-Id: <20220314213226.362217-3-v.sementsov-og@mail.ru>
[eblake: Adjust S-o-b to Vladimir's new email, with permission]
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
2022-03-15 00:32:25 +03:00
|
|
|
{ 'include': 'block-core.json' }
|
2020-09-24 18:26:48 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @NbdServerOptions:
|
|
|
|
#
|
|
|
|
# Keep this type consistent with the nbd-server-start arguments. The only
|
|
|
|
# intended difference is using SocketAddress instead of SocketAddressLegacy.
|
|
|
|
#
|
|
|
|
# @addr: Address on which to listen.
|
|
|
|
# @tls-creds: ID of the TLS credentials object (since 2.6).
|
|
|
|
# @tls-authz: ID of the QAuthZ authorization object used to validate
|
|
|
|
# the client's x509 distinguished name. This object is
|
|
|
|
# is only resolved at time of use, so can be deleted and
|
|
|
|
# recreated on the fly while the NBD server is active.
|
|
|
|
# If missing, it will default to denying access (since 4.0).
|
2020-09-24 18:26:54 +03:00
|
|
|
# @max-connections: The maximum number of connections to allow at the same
|
nbd/server: Allow MULTI_CONN for shared writable exports
According to the NBD spec, a server that advertises
NBD_FLAG_CAN_MULTI_CONN promises that multiple client connections will
not see any cache inconsistencies: when properly separated by a single
flush, actions performed by one client will be visible to another
client, regardless of which client did the flush.
We always satisfy these conditions in qemu - even when we support
multiple clients, ALL clients go through a single point of reference
into the block layer, with no local caching. The effect of one client
is instantly visible to the next client. Even if our backend were a
network device, we argue that any multi-path caching effects that
would cause inconsistencies in back-to-back actions not seeing the
effect of previous actions would be a bug in that backend, and not the
fault of caching in qemu. As such, it is safe to unconditionally
advertise CAN_MULTI_CONN for any qemu NBD server situation that
supports parallel clients.
Note, however, that we don't want to advertise CAN_MULTI_CONN when we
know that a second client cannot connect (for historical reasons,
qemu-nbd defaults to a single connection while nbd-server-add and QMP
commands default to unlimited connections; but we already have
existing means to let either style of NBD server creation alter those
defaults). This is visible by no longer advertising MULTI_CONN for
'qemu-nbd -r' without -e, as in the iotest nbd-qemu-allocation.
The harder part of this patch is setting up an iotest to demonstrate
behavior of multiple NBD clients to a single server. It might be
possible with parallel qemu-io processes, but I found it easier to do
in python with the help of libnbd, and help from Nir and Vladimir in
writing the test.
Signed-off-by: Eric Blake <eblake@redhat.com>
Suggested-by: Nir Soffer <nsoffer@redhat.com>
Suggested-by: Vladimir Sementsov-Ogievskiy <v.sementsov-og@mail.ru>
Message-Id: <20220512004924.417153-3-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-05-12 03:49:24 +03:00
|
|
|
# time, 0 for unlimited. Setting this to 1 also stops
|
|
|
|
# the server from advertising multiple client support
|
|
|
|
# (since 5.2; default: 0)
|
2020-09-24 18:26:48 +03:00
|
|
|
#
|
|
|
|
# Since: 4.2
|
|
|
|
##
|
|
|
|
{ 'struct': 'NbdServerOptions',
|
|
|
|
'data': { 'addr': 'SocketAddress',
|
|
|
|
'*tls-creds': 'str',
|
2020-09-24 18:26:54 +03:00
|
|
|
'*tls-authz': 'str',
|
|
|
|
'*max-connections': 'uint32' } }
|
2020-09-24 18:26:48 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @nbd-server-start:
|
|
|
|
#
|
|
|
|
# Start an NBD server listening on the given host and port. Block
|
|
|
|
# devices can then be exported using @nbd-server-add. The NBD
|
|
|
|
# server will present them as named exports; for example, another
|
|
|
|
# QEMU instance could refer to them as "nbd:HOST:PORT:exportname=NAME".
|
|
|
|
#
|
|
|
|
# Keep this type consistent with the NbdServerOptions type. The only intended
|
|
|
|
# difference is using SocketAddressLegacy instead of SocketAddress.
|
|
|
|
#
|
|
|
|
# @addr: Address on which to listen.
|
|
|
|
# @tls-creds: ID of the TLS credentials object (since 2.6).
|
|
|
|
# @tls-authz: ID of the QAuthZ authorization object used to validate
|
|
|
|
# the client's x509 distinguished name. This object is
|
|
|
|
# is only resolved at time of use, so can be deleted and
|
|
|
|
# recreated on the fly while the NBD server is active.
|
|
|
|
# If missing, it will default to denying access (since 4.0).
|
2020-09-24 18:26:54 +03:00
|
|
|
# @max-connections: The maximum number of connections to allow at the same
|
nbd/server: Allow MULTI_CONN for shared writable exports
According to the NBD spec, a server that advertises
NBD_FLAG_CAN_MULTI_CONN promises that multiple client connections will
not see any cache inconsistencies: when properly separated by a single
flush, actions performed by one client will be visible to another
client, regardless of which client did the flush.
We always satisfy these conditions in qemu - even when we support
multiple clients, ALL clients go through a single point of reference
into the block layer, with no local caching. The effect of one client
is instantly visible to the next client. Even if our backend were a
network device, we argue that any multi-path caching effects that
would cause inconsistencies in back-to-back actions not seeing the
effect of previous actions would be a bug in that backend, and not the
fault of caching in qemu. As such, it is safe to unconditionally
advertise CAN_MULTI_CONN for any qemu NBD server situation that
supports parallel clients.
Note, however, that we don't want to advertise CAN_MULTI_CONN when we
know that a second client cannot connect (for historical reasons,
qemu-nbd defaults to a single connection while nbd-server-add and QMP
commands default to unlimited connections; but we already have
existing means to let either style of NBD server creation alter those
defaults). This is visible by no longer advertising MULTI_CONN for
'qemu-nbd -r' without -e, as in the iotest nbd-qemu-allocation.
The harder part of this patch is setting up an iotest to demonstrate
behavior of multiple NBD clients to a single server. It might be
possible with parallel qemu-io processes, but I found it easier to do
in python with the help of libnbd, and help from Nir and Vladimir in
writing the test.
Signed-off-by: Eric Blake <eblake@redhat.com>
Suggested-by: Nir Soffer <nsoffer@redhat.com>
Suggested-by: Vladimir Sementsov-Ogievskiy <v.sementsov-og@mail.ru>
Message-Id: <20220512004924.417153-3-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-05-12 03:49:24 +03:00
|
|
|
# time, 0 for unlimited. Setting this to 1 also stops
|
|
|
|
# the server from advertising multiple client support
|
|
|
|
# (since 5.2; default: 0).
|
2020-09-24 18:26:48 +03:00
|
|
|
#
|
|
|
|
# Returns: error if the server is already running.
|
|
|
|
#
|
2020-11-18 09:41:58 +03:00
|
|
|
# Since: 1.3
|
2020-09-24 18:26:48 +03:00
|
|
|
##
|
|
|
|
{ 'command': 'nbd-server-start',
|
|
|
|
'data': { 'addr': 'SocketAddressLegacy',
|
|
|
|
'*tls-creds': 'str',
|
2020-09-24 18:26:54 +03:00
|
|
|
'*tls-authz': 'str',
|
|
|
|
'*max-connections': 'uint32' } }
|
2020-09-24 18:26:48 +03:00
|
|
|
|
|
|
|
##
|
2020-10-27 08:05:49 +03:00
|
|
|
# @BlockExportOptionsNbdBase:
|
2020-09-24 18:26:48 +03:00
|
|
|
#
|
2020-10-27 08:05:49 +03:00
|
|
|
# An NBD block export (common options shared between nbd-server-add and
|
|
|
|
# the NBD branch of block-export-add).
|
2020-09-24 18:26:48 +03:00
|
|
|
#
|
|
|
|
# @name: Export name. If unspecified, the @device parameter is used as the
|
|
|
|
# export name. (Since 2.12)
|
|
|
|
#
|
|
|
|
# @description: Free-form description of the export, up to 4096 bytes.
|
|
|
|
# (Since 5.0)
|
|
|
|
#
|
|
|
|
# Since: 5.0
|
|
|
|
##
|
2020-10-27 08:05:49 +03:00
|
|
|
{ 'struct': 'BlockExportOptionsNbdBase',
|
|
|
|
'data': { '*name': 'str', '*description': 'str' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @BlockExportOptionsNbd:
|
|
|
|
#
|
|
|
|
# An NBD block export (distinct options used in the NBD branch of
|
|
|
|
# block-export-add).
|
|
|
|
#
|
|
|
|
# @bitmaps: Also export each of the named dirty bitmaps reachable from
|
|
|
|
# @device, so the NBD client can use NBD_OPT_SET_META_CONTEXT with
|
|
|
|
# the metadata context name "qemu:dirty-bitmap:BITMAP" to inspect
|
|
|
|
# each bitmap.
|
qapi: nbd-export: allow select bitmaps by node/name pair
Hi all! Current logic of relying on search through backing chain is not
safe neither convenient.
Sometimes it leads to necessity of extra bitmap copying. Also, we are
going to add "snapshot-access" driver, to access some snapshot state
through NBD. And this driver is not formally a filter, and of course
it's not a COW format driver. So, searching through backing chain will
not work. Instead of widening the workaround of bitmap searching, let's
extend the interface so that user can select bitmap precisely.
Note, that checking for bitmap active status is not copied to the new
API, I don't see a reason for it, user should understand the risks. And
anyway, bitmap from other node is unrelated to this export being
read-only or read-write.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@openvz.org>
Message-Id: <20220314213226.362217-3-v.sementsov-og@mail.ru>
[eblake: Adjust S-o-b to Vladimir's new email, with permission]
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
2022-03-15 00:32:25 +03:00
|
|
|
# Since 7.1 bitmap may be specified by node/name pair.
|
2020-10-27 08:05:49 +03:00
|
|
|
#
|
2020-10-27 08:05:55 +03:00
|
|
|
# @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)
|
|
|
|
#
|
2020-10-27 08:05:49 +03:00
|
|
|
# Since: 5.2
|
|
|
|
##
|
2020-09-24 18:26:49 +03:00
|
|
|
{ 'struct': 'BlockExportOptionsNbd',
|
2020-10-27 08:05:49 +03:00
|
|
|
'base': 'BlockExportOptionsNbdBase',
|
qapi: nbd-export: allow select bitmaps by node/name pair
Hi all! Current logic of relying on search through backing chain is not
safe neither convenient.
Sometimes it leads to necessity of extra bitmap copying. Also, we are
going to add "snapshot-access" driver, to access some snapshot state
through NBD. And this driver is not formally a filter, and of course
it's not a COW format driver. So, searching through backing chain will
not work. Instead of widening the workaround of bitmap searching, let's
extend the interface so that user can select bitmap precisely.
Note, that checking for bitmap active status is not copied to the new
API, I don't see a reason for it, user should understand the risks. And
anyway, bitmap from other node is unrelated to this export being
read-only or read-write.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@openvz.org>
Message-Id: <20220314213226.362217-3-v.sementsov-og@mail.ru>
[eblake: Adjust S-o-b to Vladimir's new email, with permission]
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
2022-03-15 00:32:25 +03:00
|
|
|
'data': { '*bitmaps': ['BlockDirtyBitmapOrStr'],
|
|
|
|
'*allocation-depth': 'bool' } }
|
2020-09-24 18:27:01 +03:00
|
|
|
|
2020-09-24 18:15:47 +03:00
|
|
|
##
|
|
|
|
# @BlockExportOptionsVhostUserBlk:
|
|
|
|
#
|
|
|
|
# A vhost-user-blk block export.
|
|
|
|
#
|
|
|
|
# @addr: The vhost-user socket on which to listen. Both 'unix' and 'fd'
|
|
|
|
# SocketAddress types are supported. Passed fds must be UNIX domain
|
|
|
|
# sockets.
|
|
|
|
# @logical-block-size: Logical block size in bytes. Defaults to 512 bytes.
|
2020-10-01 17:46:03 +03:00
|
|
|
# @num-queues: Number of request virtqueues. Must be greater than 0. Defaults
|
|
|
|
# to 1.
|
2020-09-24 18:15:47 +03:00
|
|
|
#
|
|
|
|
# Since: 5.2
|
|
|
|
##
|
|
|
|
{ 'struct': 'BlockExportOptionsVhostUserBlk',
|
2020-10-01 17:46:03 +03:00
|
|
|
'data': { 'addr': 'SocketAddress',
|
|
|
|
'*logical-block-size': 'size',
|
|
|
|
'*num-queues': 'uint16'} }
|
2020-09-24 18:15:47 +03:00
|
|
|
|
export/fuse: Add allow-other option
Without the allow_other mount option, no user (not even root) but the
one who started qemu/the storage daemon can access the export. Allow
users to configure the export such that such accesses are possible.
While allow_other is probably what users want, we cannot make it an
unconditional default, because passing it is only possible (for non-root
users) if the global fuse.conf configuration file allows it. Thus, the
default is an 'auto' mode, in which we first try with allow_other, and
then fall back to without.
FuseExport.allow_other reports whether allow_other was actually used as
a mount option or not. Currently, this information is not used, but a
future patch will let this field decide whether e.g. an export's UID and
GID can be changed through chmod.
One notable thing about 'auto' mode is that libfuse may print error
messages directly to stderr, and so may fusermount (which it executes).
Our export code cannot really filter or hide them. Therefore, if 'auto'
fails its first attempt and has to fall back, fusermount will print an
error message that mounting with allow_other failed.
This behavior necessitates a change to iotest 308, namely we need to
filter out this error message (because if the first attempt at mounting
with allow_other succeeds, there will be no such message).
Furthermore, common.rc's _make_test_img should use allow-other=off for
FUSE exports, because iotests generally do not need to access images
from other users, so allow-other=on or allow-other=auto have no
advantage. OTOH, allow-other=on will not work on systems where
user_allow_other is disabled, and with allow-other=auto, we get said
error message that we would need to filter out again. Just disabling
allow-other is simplest.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20210625142317.271673-3-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-06-25 17:23:13 +03:00
|
|
|
##
|
|
|
|
# @FuseExportAllowOther:
|
|
|
|
#
|
|
|
|
# Possible allow_other modes for FUSE exports.
|
|
|
|
#
|
|
|
|
# @off: Do not pass allow_other as a mount option.
|
|
|
|
#
|
|
|
|
# @on: Pass allow_other as a mount option.
|
|
|
|
#
|
|
|
|
# @auto: Try mounting with allow_other first, and if that fails, retry
|
|
|
|
# without allow_other.
|
|
|
|
#
|
|
|
|
# Since: 6.1
|
|
|
|
##
|
|
|
|
{ 'enum': 'FuseExportAllowOther',
|
|
|
|
'data': ['off', 'on', 'auto'] }
|
|
|
|
|
2020-10-27 22:05:42 +03:00
|
|
|
##
|
|
|
|
# @BlockExportOptionsFuse:
|
|
|
|
#
|
|
|
|
# Options for exporting a block graph node on some (file) mountpoint
|
|
|
|
# as a raw image.
|
|
|
|
#
|
|
|
|
# @mountpoint: Path on which to export the block device via FUSE.
|
|
|
|
# This must point to an existing regular file.
|
|
|
|
#
|
2020-10-27 22:05:44 +03:00
|
|
|
# @growable: Whether writes beyond the EOF should grow the block node
|
|
|
|
# accordingly. (default: false)
|
|
|
|
#
|
export/fuse: Add allow-other option
Without the allow_other mount option, no user (not even root) but the
one who started qemu/the storage daemon can access the export. Allow
users to configure the export such that such accesses are possible.
While allow_other is probably what users want, we cannot make it an
unconditional default, because passing it is only possible (for non-root
users) if the global fuse.conf configuration file allows it. Thus, the
default is an 'auto' mode, in which we first try with allow_other, and
then fall back to without.
FuseExport.allow_other reports whether allow_other was actually used as
a mount option or not. Currently, this information is not used, but a
future patch will let this field decide whether e.g. an export's UID and
GID can be changed through chmod.
One notable thing about 'auto' mode is that libfuse may print error
messages directly to stderr, and so may fusermount (which it executes).
Our export code cannot really filter or hide them. Therefore, if 'auto'
fails its first attempt and has to fall back, fusermount will print an
error message that mounting with allow_other failed.
This behavior necessitates a change to iotest 308, namely we need to
filter out this error message (because if the first attempt at mounting
with allow_other succeeds, there will be no such message).
Furthermore, common.rc's _make_test_img should use allow-other=off for
FUSE exports, because iotests generally do not need to access images
from other users, so allow-other=on or allow-other=auto have no
advantage. OTOH, allow-other=on will not work on systems where
user_allow_other is disabled, and with allow-other=auto, we get said
error message that we would need to filter out again. Just disabling
allow-other is simplest.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20210625142317.271673-3-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-06-25 17:23:13 +03:00
|
|
|
# @allow-other: If this is off, only qemu's user is allowed access to
|
|
|
|
# this export. That cannot be changed even with chmod or
|
|
|
|
# chown.
|
|
|
|
# Enabling this option will allow other users access to
|
|
|
|
# the export with the FUSE mount option "allow_other".
|
|
|
|
# Note that using allow_other as a non-root user requires
|
|
|
|
# user_allow_other to be enabled in the global fuse.conf
|
|
|
|
# configuration file.
|
|
|
|
# In auto mode (the default), the FUSE export driver will
|
|
|
|
# first attempt to mount the export with allow_other, and
|
|
|
|
# if that fails, try again without.
|
|
|
|
# (since 6.1; default: auto)
|
|
|
|
#
|
2020-10-27 22:05:42 +03:00
|
|
|
# Since: 6.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'BlockExportOptionsFuse',
|
2020-10-27 22:05:44 +03:00
|
|
|
'data': { 'mountpoint': 'str',
|
export/fuse: Add allow-other option
Without the allow_other mount option, no user (not even root) but the
one who started qemu/the storage daemon can access the export. Allow
users to configure the export such that such accesses are possible.
While allow_other is probably what users want, we cannot make it an
unconditional default, because passing it is only possible (for non-root
users) if the global fuse.conf configuration file allows it. Thus, the
default is an 'auto' mode, in which we first try with allow_other, and
then fall back to without.
FuseExport.allow_other reports whether allow_other was actually used as
a mount option or not. Currently, this information is not used, but a
future patch will let this field decide whether e.g. an export's UID and
GID can be changed through chmod.
One notable thing about 'auto' mode is that libfuse may print error
messages directly to stderr, and so may fusermount (which it executes).
Our export code cannot really filter or hide them. Therefore, if 'auto'
fails its first attempt and has to fall back, fusermount will print an
error message that mounting with allow_other failed.
This behavior necessitates a change to iotest 308, namely we need to
filter out this error message (because if the first attempt at mounting
with allow_other succeeds, there will be no such message).
Furthermore, common.rc's _make_test_img should use allow-other=off for
FUSE exports, because iotests generally do not need to access images
from other users, so allow-other=on or allow-other=auto have no
advantage. OTOH, allow-other=on will not work on systems where
user_allow_other is disabled, and with allow-other=auto, we get said
error message that we would need to filter out again. Just disabling
allow-other is simplest.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20210625142317.271673-3-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-06-25 17:23:13 +03:00
|
|
|
'*growable': 'bool',
|
|
|
|
'*allow-other': 'FuseExportAllowOther' },
|
2021-08-04 11:31:05 +03:00
|
|
|
'if': 'CONFIG_FUSE' }
|
2020-10-27 22:05:42 +03:00
|
|
|
|
2020-09-24 18:27:01 +03:00
|
|
|
##
|
|
|
|
# @NbdServerAddOptions:
|
|
|
|
#
|
2020-10-27 08:05:49 +03:00
|
|
|
# An NBD block export, per legacy nbd-server-add command.
|
2020-09-24 18:27:01 +03:00
|
|
|
#
|
|
|
|
# @device: The device name or node name of the node to be exported
|
|
|
|
#
|
2020-09-24 18:27:11 +03:00
|
|
|
# @writable: Whether clients should be able to write to the device via the
|
|
|
|
# NBD connection (default false).
|
|
|
|
#
|
2020-10-27 08:05:49 +03:00
|
|
|
# @bitmap: Also export a single dirty bitmap reachable from @device, so the
|
|
|
|
# NBD client can use NBD_OPT_SET_META_CONTEXT with the metadata
|
|
|
|
# context name "qemu:dirty-bitmap:BITMAP" to inspect the bitmap
|
|
|
|
# (since 4.0).
|
|
|
|
#
|
2020-09-24 18:27:01 +03:00
|
|
|
# Since: 5.0
|
|
|
|
##
|
|
|
|
{ 'struct': 'NbdServerAddOptions',
|
2020-10-27 08:05:49 +03:00
|
|
|
'base': 'BlockExportOptionsNbdBase',
|
2020-09-24 18:27:11 +03:00
|
|
|
'data': { 'device': 'str',
|
2020-10-27 08:05:49 +03:00
|
|
|
'*writable': 'bool', '*bitmap': 'str' } }
|
2020-09-24 18:26:48 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @nbd-server-add:
|
|
|
|
#
|
|
|
|
# Export a block node to QEMU's embedded NBD server.
|
|
|
|
#
|
2020-09-24 18:27:04 +03:00
|
|
|
# The export name will be used as the id for the resulting block export.
|
|
|
|
#
|
2020-09-24 18:27:13 +03:00
|
|
|
# Features:
|
|
|
|
# @deprecated: This command is deprecated. Use @block-export-add instead.
|
|
|
|
#
|
2020-09-24 18:26:48 +03:00
|
|
|
# Returns: error if the server is not running, or export with the same name
|
|
|
|
# already exists.
|
|
|
|
#
|
2020-11-18 09:41:58 +03:00
|
|
|
# Since: 1.3
|
2020-09-24 18:26:48 +03:00
|
|
|
##
|
|
|
|
{ 'command': 'nbd-server-add',
|
2020-09-24 18:27:13 +03:00
|
|
|
'data': 'NbdServerAddOptions', 'boxed': true, 'features': ['deprecated'] }
|
2020-09-24 18:26:48 +03:00
|
|
|
|
|
|
|
##
|
2020-09-24 18:27:06 +03:00
|
|
|
# @BlockExportRemoveMode:
|
2020-09-24 18:26:48 +03:00
|
|
|
#
|
2020-09-24 18:27:06 +03:00
|
|
|
# Mode for removing a block export.
|
2020-09-24 18:26:48 +03:00
|
|
|
#
|
|
|
|
# @safe: Remove export if there are no existing connections, fail otherwise.
|
|
|
|
#
|
|
|
|
# @hard: Drop all connections immediately and remove export.
|
|
|
|
#
|
2022-03-28 17:05:51 +03:00
|
|
|
# TODO: Potential additional modes to be added in the future:
|
2020-09-24 18:26:48 +03:00
|
|
|
#
|
2022-03-28 17:05:51 +03:00
|
|
|
# hide: Just hide export from new clients, leave existing connections as is.
|
|
|
|
# Remove export after all clients are disconnected.
|
2020-09-24 18:26:48 +03:00
|
|
|
#
|
2022-03-28 17:05:51 +03:00
|
|
|
# soft: Hide export from new clients, answer with ESHUTDOWN for all further
|
|
|
|
# requests from existing clients.
|
2020-09-24 18:26:48 +03:00
|
|
|
#
|
|
|
|
# Since: 2.12
|
|
|
|
##
|
2020-09-24 18:27:06 +03:00
|
|
|
{'enum': 'BlockExportRemoveMode', 'data': ['safe', 'hard']}
|
2020-09-24 18:26:48 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @nbd-server-remove:
|
|
|
|
#
|
|
|
|
# Remove NBD export by name.
|
|
|
|
#
|
2020-09-24 18:27:06 +03:00
|
|
|
# @name: Block export id.
|
2020-09-24 18:26:48 +03:00
|
|
|
#
|
2020-09-24 18:27:06 +03:00
|
|
|
# @mode: Mode of command operation. See @BlockExportRemoveMode description.
|
2020-09-24 18:26:48 +03:00
|
|
|
# Default is 'safe'.
|
|
|
|
#
|
2020-09-24 18:27:13 +03:00
|
|
|
# Features:
|
|
|
|
# @deprecated: This command is deprecated. Use @block-export-del instead.
|
|
|
|
#
|
2020-09-24 18:26:48 +03:00
|
|
|
# Returns: error if
|
|
|
|
# - the server is not running
|
|
|
|
# - export is not found
|
|
|
|
# - mode is 'safe' and there are existing connections
|
|
|
|
#
|
|
|
|
# Since: 2.12
|
|
|
|
##
|
|
|
|
{ 'command': 'nbd-server-remove',
|
2020-09-24 18:27:13 +03:00
|
|
|
'data': {'name': 'str', '*mode': 'BlockExportRemoveMode'},
|
|
|
|
'features': ['deprecated'] }
|
2020-09-24 18:26:48 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @nbd-server-stop:
|
|
|
|
#
|
|
|
|
# Stop QEMU's embedded NBD server, and unregister all devices previously
|
|
|
|
# added via @nbd-server-add.
|
|
|
|
#
|
2020-11-18 09:41:58 +03:00
|
|
|
# Since: 1.3
|
2020-09-24 18:26:48 +03:00
|
|
|
##
|
|
|
|
{ 'command': 'nbd-server-stop' }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @BlockExportType:
|
|
|
|
#
|
|
|
|
# An enumeration of block export types
|
|
|
|
#
|
|
|
|
# @nbd: NBD export
|
2020-09-24 18:15:47 +03:00
|
|
|
# @vhost-user-blk: vhost-user-blk export (since 5.2)
|
2020-10-27 22:05:42 +03:00
|
|
|
# @fuse: FUSE export (since: 6.0)
|
2020-09-24 18:26:48 +03:00
|
|
|
#
|
|
|
|
# Since: 4.2
|
|
|
|
##
|
|
|
|
{ 'enum': 'BlockExportType',
|
2022-01-07 13:54:20 +03:00
|
|
|
'data': [ 'nbd',
|
2022-01-19 15:14:39 +03:00
|
|
|
{ 'name': 'vhost-user-blk',
|
|
|
|
'if': 'CONFIG_VHOST_USER_BLK_SERVER' },
|
2021-08-04 11:31:05 +03:00
|
|
|
{ 'name': 'fuse', 'if': 'CONFIG_FUSE' } ] }
|
2020-09-24 18:26:48 +03:00
|
|
|
|
|
|
|
##
|
2020-09-24 18:26:49 +03:00
|
|
|
# @BlockExportOptions:
|
2020-09-24 18:26:48 +03:00
|
|
|
#
|
|
|
|
# Describes a block export, i.e. how single node should be exported on an
|
|
|
|
# external interface.
|
|
|
|
#
|
2020-09-24 18:27:04 +03:00
|
|
|
# @id: A unique identifier for the block export (across all export types)
|
|
|
|
#
|
2020-09-24 18:27:01 +03:00
|
|
|
# @node-name: The node name of the block node to be exported (since: 5.2)
|
|
|
|
#
|
2020-09-24 18:27:11 +03:00
|
|
|
# @writable: True if clients should be able to write to the export
|
|
|
|
# (default false)
|
|
|
|
#
|
2020-09-24 18:26:55 +03:00
|
|
|
# @writethrough: If true, caches are flushed after every write request to the
|
|
|
|
# export before completion is signalled. (since: 5.2;
|
|
|
|
# default: false)
|
|
|
|
#
|
2020-09-29 15:55:16 +03:00
|
|
|
# @iothread: The name of the iothread object where the export will run. The
|
|
|
|
# default is to use the thread currently associated with the
|
|
|
|
# block node. (since: 5.2)
|
|
|
|
#
|
|
|
|
# @fixed-iothread: True prevents the block node from being moved to another
|
|
|
|
# thread while the export is active. If true and @iothread is
|
|
|
|
# given, export creation fails if the block node cannot be
|
|
|
|
# moved to the iothread. The default is false. (since: 5.2)
|
|
|
|
#
|
2020-09-24 18:26:48 +03:00
|
|
|
# Since: 4.2
|
|
|
|
##
|
2020-09-24 18:26:49 +03:00
|
|
|
{ 'union': 'BlockExportOptions',
|
2020-09-24 18:26:55 +03:00
|
|
|
'base': { 'type': 'BlockExportType',
|
2020-09-24 18:27:04 +03:00
|
|
|
'id': 'str',
|
2020-10-01 17:46:03 +03:00
|
|
|
'*fixed-iothread': 'bool',
|
|
|
|
'*iothread': 'str',
|
2020-09-24 18:27:01 +03:00
|
|
|
'node-name': 'str',
|
2020-09-24 18:27:11 +03:00
|
|
|
'*writable': 'bool',
|
2020-09-24 18:26:55 +03:00
|
|
|
'*writethrough': 'bool' },
|
2020-09-24 18:26:48 +03:00
|
|
|
'discriminator': 'type',
|
|
|
|
'data': {
|
2020-09-24 18:15:47 +03:00
|
|
|
'nbd': 'BlockExportOptionsNbd',
|
2022-01-07 13:54:20 +03:00
|
|
|
'vhost-user-blk': { 'type': 'BlockExportOptionsVhostUserBlk',
|
|
|
|
'if': 'CONFIG_VHOST_USER_BLK_SERVER' },
|
2020-10-27 22:05:42 +03:00
|
|
|
'fuse': { 'type': 'BlockExportOptionsFuse',
|
2021-08-04 11:31:05 +03:00
|
|
|
'if': 'CONFIG_FUSE' }
|
2020-09-24 18:26:48 +03:00
|
|
|
} }
|
2020-09-24 18:26:50 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @block-export-add:
|
|
|
|
#
|
|
|
|
# Creates a new block export.
|
|
|
|
#
|
|
|
|
# Since: 5.2
|
|
|
|
##
|
|
|
|
{ 'command': 'block-export-add',
|
|
|
|
'data': 'BlockExportOptions', 'boxed': true }
|
2020-09-24 18:27:06 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @block-export-del:
|
|
|
|
#
|
|
|
|
# Request to remove a block export. This drops the user's reference to the
|
|
|
|
# export, but the export may still stay around after this command returns until
|
|
|
|
# the shutdown of the export has completed.
|
|
|
|
#
|
|
|
|
# @id: Block export id.
|
|
|
|
#
|
|
|
|
# @mode: Mode of command operation. See @BlockExportRemoveMode description.
|
|
|
|
# Default is 'safe'.
|
|
|
|
#
|
|
|
|
# Returns: Error if the export is not found or @mode is 'safe' and the export
|
|
|
|
# is still in use (e.g. by existing client connections)
|
|
|
|
#
|
|
|
|
# Since: 5.2
|
|
|
|
##
|
|
|
|
{ 'command': 'block-export-del',
|
|
|
|
'data': { 'id': 'str', '*mode': 'BlockExportRemoveMode' } }
|
2020-09-24 18:27:07 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @BLOCK_EXPORT_DELETED:
|
|
|
|
#
|
|
|
|
# Emitted when a block export is removed and its id can be reused.
|
|
|
|
#
|
|
|
|
# @id: Block export id.
|
|
|
|
#
|
|
|
|
# Since: 5.2
|
|
|
|
##
|
|
|
|
{ 'event': 'BLOCK_EXPORT_DELETED',
|
|
|
|
'data': { 'id': 'str' } }
|
2020-09-24 18:27:10 +03:00
|
|
|
|
|
|
|
##
|
|
|
|
# @BlockExportInfo:
|
|
|
|
#
|
|
|
|
# Information about a single block export.
|
|
|
|
#
|
|
|
|
# @id: The unique identifier for the block export
|
|
|
|
#
|
|
|
|
# @type: The block export type
|
|
|
|
#
|
|
|
|
# @node-name: The node name of the block node that is exported
|
|
|
|
#
|
|
|
|
# @shutting-down: True if the export is shutting down (e.g. after a
|
|
|
|
# block-export-del command, but before the shutdown has
|
|
|
|
# completed)
|
|
|
|
#
|
2022-05-03 10:37:35 +03:00
|
|
|
# Since: 5.2
|
2020-09-24 18:27:10 +03:00
|
|
|
##
|
|
|
|
{ 'struct': 'BlockExportInfo',
|
|
|
|
'data': { 'id': 'str',
|
|
|
|
'type': 'BlockExportType',
|
|
|
|
'node-name': 'str',
|
|
|
|
'shutting-down': 'bool' } }
|
|
|
|
|
|
|
|
##
|
|
|
|
# @query-block-exports:
|
|
|
|
#
|
|
|
|
# Returns: A list of BlockExportInfo describing all block exports
|
|
|
|
#
|
|
|
|
# Since: 5.2
|
|
|
|
##
|
|
|
|
{ 'command': 'query-block-exports', 'returns': ['BlockExportInfo'] }
|