2008-05-28 05:13:40 +08:00
|
|
|
@example
|
|
|
|
@c man begin SYNOPSIS
|
2016-01-05 15:33:31 +08:00
|
|
|
@command{qemu-nbd} [OPTION]... @var{filename}
|
|
|
|
|
qemu-nbd: Add --list option
We want to be able to detect whether a given qemu NBD server is
exposing the right export(s) and dirty bitmaps, at least for
regression testing. We could use 'nbd-client -l' from the upstream
NBD project to list exports, but it's annoying to rely on
out-of-tree binaries; furthermore, nbd-client doesn't necessarily
know about all of the qemu NBD extensions. Thus, it is time to add
a new mode to qemu-nbd that merely sniffs all possible information
from the server during handshake phase, then disconnects and dumps
the information.
This patch actually implements --list/-L, while reusing other
options such as --tls-creds for now designating how to connect
as the client (rather than their non-list usage of how to operate
as the server).
I debated about adding this functionality to something akin to
'qemu-img info' - but that tool does not readily lend itself
to connecting to an arbitrary NBD server without also tying to
a specific export (I may, however, still add ImageInfoSpecificNBD
for reporting the bitmaps available when connecting to a single
export). And, while it may feel a bit odd that normally
qemu-nbd is a server but 'qemu-nbd -L' is a client, we are not
really making the qemu-nbd binary that much larger, because
'qemu-nbd -c' has to operate as both server and client
simultaneously across two threads when feeding the kernel module
for /dev/nbdN access.
Sample output:
$ qemu-nbd -L
exports available: 1
export: ''
size: 65536
flags: 0x4ed ( flush fua trim zeroes df cache )
min block: 512
opt block: 4096
max block: 33554432
available meta contexts: 1
base:allocation
Note that the output only lists sizes if the server sent
NBD_FLAG_HAS_FLAGS, because a newstyle server does not give
the size otherwise. It has the side effect that for really
old servers that did not send any flags, the size is not
output even though it was available. However, I'm not too
concerned about that - oldstyle servers are (rightfully)
getting less common to encounter (qemu 3.0 was the last
version where we even serve it), and most existing servers
that still even offer oldstyle negotiation (such as nbdkit)
still send flags (since that was added to the NBD protocol
in 2007 to permit read-only connections).
Not done here, but maybe worth future experiments: capture
the meat of NBDExportInfo into a QAPI struct, and use the
generated QAPI pretty-printers instead of hand-rolling our
output loop. It would also permit us to add a JSON output
mode for machine parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20190117193658.16413-20-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2019-01-18 03:36:56 +08:00
|
|
|
@command{qemu-nbd} @option{-L} [OPTION]...
|
|
|
|
|
2016-01-05 15:33:31 +08:00
|
|
|
@command{qemu-nbd} @option{-d} @var{dev}
|
2008-05-28 05:13:40 +08:00
|
|
|
@c man end
|
|
|
|
@end example
|
|
|
|
|
|
|
|
@c man begin DESCRIPTION
|
|
|
|
|
2016-01-05 15:33:31 +08:00
|
|
|
Export a QEMU disk image using the NBD protocol.
|
2008-05-28 05:13:40 +08:00
|
|
|
|
2019-01-18 03:36:40 +08:00
|
|
|
Other uses:
|
|
|
|
@itemize
|
|
|
|
@item
|
|
|
|
Bind a /dev/nbdX block device to a QEMU server (on Linux).
|
qemu-nbd: Add --list option
We want to be able to detect whether a given qemu NBD server is
exposing the right export(s) and dirty bitmaps, at least for
regression testing. We could use 'nbd-client -l' from the upstream
NBD project to list exports, but it's annoying to rely on
out-of-tree binaries; furthermore, nbd-client doesn't necessarily
know about all of the qemu NBD extensions. Thus, it is time to add
a new mode to qemu-nbd that merely sniffs all possible information
from the server during handshake phase, then disconnects and dumps
the information.
This patch actually implements --list/-L, while reusing other
options such as --tls-creds for now designating how to connect
as the client (rather than their non-list usage of how to operate
as the server).
I debated about adding this functionality to something akin to
'qemu-img info' - but that tool does not readily lend itself
to connecting to an arbitrary NBD server without also tying to
a specific export (I may, however, still add ImageInfoSpecificNBD
for reporting the bitmaps available when connecting to a single
export). And, while it may feel a bit odd that normally
qemu-nbd is a server but 'qemu-nbd -L' is a client, we are not
really making the qemu-nbd binary that much larger, because
'qemu-nbd -c' has to operate as both server and client
simultaneously across two threads when feeding the kernel module
for /dev/nbdN access.
Sample output:
$ qemu-nbd -L
exports available: 1
export: ''
size: 65536
flags: 0x4ed ( flush fua trim zeroes df cache )
min block: 512
opt block: 4096
max block: 33554432
available meta contexts: 1
base:allocation
Note that the output only lists sizes if the server sent
NBD_FLAG_HAS_FLAGS, because a newstyle server does not give
the size otherwise. It has the side effect that for really
old servers that did not send any flags, the size is not
output even though it was available. However, I'm not too
concerned about that - oldstyle servers are (rightfully)
getting less common to encounter (qemu 3.0 was the last
version where we even serve it), and most existing servers
that still even offer oldstyle negotiation (such as nbdkit)
still send flags (since that was added to the NBD protocol
in 2007 to permit read-only connections).
Not done here, but maybe worth future experiments: capture
the meat of NBDExportInfo into a QAPI struct, and use the
generated QAPI pretty-printers instead of hand-rolling our
output loop. It would also permit us to add a JSON output
mode for machine parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20190117193658.16413-20-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2019-01-18 03:36:56 +08:00
|
|
|
@item
|
|
|
|
As a client to query exports of a remote NBD server.
|
2019-01-18 03:36:40 +08:00
|
|
|
@end itemize
|
|
|
|
|
2008-05-28 05:13:40 +08:00
|
|
|
@c man end
|
|
|
|
|
|
|
|
@c man begin OPTIONS
|
2016-02-17 18:10:19 +08:00
|
|
|
@var{filename} is a disk image filename, or a set of block
|
2019-01-18 03:36:40 +08:00
|
|
|
driver options if @option{--image-opts} is specified.
|
2016-01-05 15:33:31 +08:00
|
|
|
|
|
|
|
@var{dev} is an NBD device.
|
|
|
|
|
2008-09-23 04:41:57 +08:00
|
|
|
@table @option
|
2016-02-11 02:41:00 +08:00
|
|
|
@item --object type,id=@var{id},...props...
|
|
|
|
Define a new instance of the @var{type} object class identified by @var{id}.
|
|
|
|
See the @code{qemu(1)} manual page for full details of the properties
|
2016-02-11 02:41:13 +08:00
|
|
|
supported. The common object types that it makes sense to define are the
|
2016-02-11 02:41:00 +08:00
|
|
|
@code{secret} object, which is used to supply passwords and/or encryption
|
2016-02-11 02:41:13 +08:00
|
|
|
keys, and the @code{tls-creds} object, which is used to supply TLS
|
qemu-nbd: Add --list option
We want to be able to detect whether a given qemu NBD server is
exposing the right export(s) and dirty bitmaps, at least for
regression testing. We could use 'nbd-client -l' from the upstream
NBD project to list exports, but it's annoying to rely on
out-of-tree binaries; furthermore, nbd-client doesn't necessarily
know about all of the qemu NBD extensions. Thus, it is time to add
a new mode to qemu-nbd that merely sniffs all possible information
from the server during handshake phase, then disconnects and dumps
the information.
This patch actually implements --list/-L, while reusing other
options such as --tls-creds for now designating how to connect
as the client (rather than their non-list usage of how to operate
as the server).
I debated about adding this functionality to something akin to
'qemu-img info' - but that tool does not readily lend itself
to connecting to an arbitrary NBD server without also tying to
a specific export (I may, however, still add ImageInfoSpecificNBD
for reporting the bitmaps available when connecting to a single
export). And, while it may feel a bit odd that normally
qemu-nbd is a server but 'qemu-nbd -L' is a client, we are not
really making the qemu-nbd binary that much larger, because
'qemu-nbd -c' has to operate as both server and client
simultaneously across two threads when feeding the kernel module
for /dev/nbdN access.
Sample output:
$ qemu-nbd -L
exports available: 1
export: ''
size: 65536
flags: 0x4ed ( flush fua trim zeroes df cache )
min block: 512
opt block: 4096
max block: 33554432
available meta contexts: 1
base:allocation
Note that the output only lists sizes if the server sent
NBD_FLAG_HAS_FLAGS, because a newstyle server does not give
the size otherwise. It has the side effect that for really
old servers that did not send any flags, the size is not
output even though it was available. However, I'm not too
concerned about that - oldstyle servers are (rightfully)
getting less common to encounter (qemu 3.0 was the last
version where we even serve it), and most existing servers
that still even offer oldstyle negotiation (such as nbdkit)
still send flags (since that was added to the NBD protocol
in 2007 to permit read-only connections).
Not done here, but maybe worth future experiments: capture
the meat of NBDExportInfo into a QAPI struct, and use the
generated QAPI pretty-printers instead of hand-rolling our
output loop. It would also permit us to add a JSON output
mode for machine parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20190117193658.16413-20-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2019-01-18 03:36:56 +08:00
|
|
|
credentials for the qemu-nbd server or client.
|
2008-09-23 04:41:57 +08:00
|
|
|
@item -p, --port=@var{port}
|
qemu-nbd: Add --list option
We want to be able to detect whether a given qemu NBD server is
exposing the right export(s) and dirty bitmaps, at least for
regression testing. We could use 'nbd-client -l' from the upstream
NBD project to list exports, but it's annoying to rely on
out-of-tree binaries; furthermore, nbd-client doesn't necessarily
know about all of the qemu NBD extensions. Thus, it is time to add
a new mode to qemu-nbd that merely sniffs all possible information
from the server during handshake phase, then disconnects and dumps
the information.
This patch actually implements --list/-L, while reusing other
options such as --tls-creds for now designating how to connect
as the client (rather than their non-list usage of how to operate
as the server).
I debated about adding this functionality to something akin to
'qemu-img info' - but that tool does not readily lend itself
to connecting to an arbitrary NBD server without also tying to
a specific export (I may, however, still add ImageInfoSpecificNBD
for reporting the bitmaps available when connecting to a single
export). And, while it may feel a bit odd that normally
qemu-nbd is a server but 'qemu-nbd -L' is a client, we are not
really making the qemu-nbd binary that much larger, because
'qemu-nbd -c' has to operate as both server and client
simultaneously across two threads when feeding the kernel module
for /dev/nbdN access.
Sample output:
$ qemu-nbd -L
exports available: 1
export: ''
size: 65536
flags: 0x4ed ( flush fua trim zeroes df cache )
min block: 512
opt block: 4096
max block: 33554432
available meta contexts: 1
base:allocation
Note that the output only lists sizes if the server sent
NBD_FLAG_HAS_FLAGS, because a newstyle server does not give
the size otherwise. It has the side effect that for really
old servers that did not send any flags, the size is not
output even though it was available. However, I'm not too
concerned about that - oldstyle servers are (rightfully)
getting less common to encounter (qemu 3.0 was the last
version where we even serve it), and most existing servers
that still even offer oldstyle negotiation (such as nbdkit)
still send flags (since that was added to the NBD protocol
in 2007 to permit read-only connections).
Not done here, but maybe worth future experiments: capture
the meat of NBDExportInfo into a QAPI struct, and use the
generated QAPI pretty-printers instead of hand-rolling our
output loop. It would also permit us to add a JSON output
mode for machine parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20190117193658.16413-20-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2019-01-18 03:36:56 +08:00
|
|
|
The TCP port to listen on as a server, or connect to as a client
|
|
|
|
(default @samp{10809}).
|
2008-09-23 04:41:57 +08:00
|
|
|
@item -o, --offset=@var{offset}
|
2019-01-18 03:36:40 +08:00
|
|
|
The offset into the image.
|
2008-09-23 04:41:57 +08:00
|
|
|
@item -b, --bind=@var{iface}
|
qemu-nbd: Add --list option
We want to be able to detect whether a given qemu NBD server is
exposing the right export(s) and dirty bitmaps, at least for
regression testing. We could use 'nbd-client -l' from the upstream
NBD project to list exports, but it's annoying to rely on
out-of-tree binaries; furthermore, nbd-client doesn't necessarily
know about all of the qemu NBD extensions. Thus, it is time to add
a new mode to qemu-nbd that merely sniffs all possible information
from the server during handshake phase, then disconnects and dumps
the information.
This patch actually implements --list/-L, while reusing other
options such as --tls-creds for now designating how to connect
as the client (rather than their non-list usage of how to operate
as the server).
I debated about adding this functionality to something akin to
'qemu-img info' - but that tool does not readily lend itself
to connecting to an arbitrary NBD server without also tying to
a specific export (I may, however, still add ImageInfoSpecificNBD
for reporting the bitmaps available when connecting to a single
export). And, while it may feel a bit odd that normally
qemu-nbd is a server but 'qemu-nbd -L' is a client, we are not
really making the qemu-nbd binary that much larger, because
'qemu-nbd -c' has to operate as both server and client
simultaneously across two threads when feeding the kernel module
for /dev/nbdN access.
Sample output:
$ qemu-nbd -L
exports available: 1
export: ''
size: 65536
flags: 0x4ed ( flush fua trim zeroes df cache )
min block: 512
opt block: 4096
max block: 33554432
available meta contexts: 1
base:allocation
Note that the output only lists sizes if the server sent
NBD_FLAG_HAS_FLAGS, because a newstyle server does not give
the size otherwise. It has the side effect that for really
old servers that did not send any flags, the size is not
output even though it was available. However, I'm not too
concerned about that - oldstyle servers are (rightfully)
getting less common to encounter (qemu 3.0 was the last
version where we even serve it), and most existing servers
that still even offer oldstyle negotiation (such as nbdkit)
still send flags (since that was added to the NBD protocol
in 2007 to permit read-only connections).
Not done here, but maybe worth future experiments: capture
the meat of NBDExportInfo into a QAPI struct, and use the
generated QAPI pretty-printers instead of hand-rolling our
output loop. It would also permit us to add a JSON output
mode for machine parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20190117193658.16413-20-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2019-01-18 03:36:56 +08:00
|
|
|
The interface to bind to as a server, or connect to as a client
|
|
|
|
(default @samp{0.0.0.0}).
|
2008-09-23 04:41:57 +08:00
|
|
|
@item -k, --socket=@var{path}
|
2019-01-18 03:36:40 +08:00
|
|
|
Use a unix socket with path @var{path}.
|
2016-02-17 18:10:19 +08:00
|
|
|
@item --image-opts
|
|
|
|
Treat @var{filename} as a set of image options, instead of a plain
|
|
|
|
filename. If this flag is specified, the @var{-f} flag should
|
|
|
|
not be used, instead the '@code{format=}' option should be set.
|
2016-01-05 15:33:31 +08:00
|
|
|
@item -f, --format=@var{fmt}
|
2016-01-05 15:33:32 +08:00
|
|
|
Force the use of the block driver for format @var{fmt} instead of
|
2019-01-18 03:36:40 +08:00
|
|
|
auto-detecting.
|
2008-05-28 05:13:40 +08:00
|
|
|
@item -r, --read-only
|
2019-01-18 03:36:40 +08:00
|
|
|
Export the disk as read-only.
|
2008-09-23 04:41:57 +08:00
|
|
|
@item -P, --partition=@var{num}
|
qemu-nbd: Deprecate qemu-nbd --partition
The existing qemu-nbd --partition code claims to handle logical
partitions up to 8, since its introduction in 2008 (commit 7a5ca86).
However, the implementation is bogus (actual MBR logical partitions
form a sort of linked list, with one partition per extended table
entry, rather than four logical partitions in a single extended
table), making the code unlikely to work for anything beyond -P5 on
actual guest images. What's more, the code does not support GPT
partitions, which are becoming more popular, and maintaining device
subsetting in both NBD and the raw device is unnecessary duplication
of effort (even if it is not too difficult).
Note that obtaining the offsets of a partition (MBR or GPT) can be
learned by using 'qemu-nbd -c /dev/nbd0 file.qcow2 && sfdisk --dump
/dev/nbd0', but by the time you've done that, you might as well
just mount /dev/nbd0p1 that the kernel creates for you instead of
bothering with qemu exporting a subset. Or, keeping to just
user-space code, use nbdkit's partition filter, which has already
known both GPT and primary MBR partitions for a while, and was
just recently enhanced to support arbitrary logical MBR parititions.
Start the clock on the deprecation cycle, with examples of how
to accomplish device subsetting without using -P.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20190125234837.2272-1-eblake@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
2019-01-26 07:48:37 +08:00
|
|
|
Deprecated: Only expose MBR partition @var{num}. Understands physical
|
|
|
|
partitions 1-4 and logical partition 5. New code should instead use
|
|
|
|
@option{--image-opts} with the raw driver wrapping a subset of the
|
|
|
|
original image.
|
2019-01-12 03:47:20 +08:00
|
|
|
@item -B, --bitmap=@var{name}
|
|
|
|
If @var{filename} has a qcow2 persistent bitmap @var{name}, expose
|
|
|
|
that bitmap via the ``qemu:dirty-bitmap:@var{name}'' context
|
|
|
|
accessible through NBD_OPT_SET_META_CONTEXT.
|
2008-07-03 19:47:46 +08:00
|
|
|
@item -s, --snapshot
|
2016-01-05 15:33:32 +08:00
|
|
|
Use @var{filename} as an external snapshot, create a temporary
|
2016-01-05 15:33:30 +08:00
|
|
|
file with backing_file=@var{filename}, redirect the write to
|
2019-01-18 03:36:40 +08:00
|
|
|
the temporary one.
|
2013-12-04 17:10:55 +08:00
|
|
|
@item -l, --load-snapshot=@var{snapshot_param}
|
2016-01-05 15:33:32 +08:00
|
|
|
Load an internal snapshot inside @var{filename} and export it
|
2016-01-05 15:33:30 +08:00
|
|
|
as an read-only device, @var{snapshot_param} format is
|
|
|
|
'snapshot.id=[ID],snapshot.name=[NAME]' or '[ID_OR_NAME]'
|
2008-07-03 19:47:46 +08:00
|
|
|
@item -n, --nocache
|
2013-02-08 20:19:07 +08:00
|
|
|
@itemx --cache=@var{cache}
|
2016-01-05 15:33:32 +08:00
|
|
|
The cache mode to be used with the file. See the documentation of
|
2016-01-05 15:33:30 +08:00
|
|
|
the emulator's @code{-drive cache=...} option for allowed values.
|
2013-02-08 20:19:07 +08:00
|
|
|
@item --aio=@var{aio}
|
2016-01-05 15:33:32 +08:00
|
|
|
Set the asynchronous I/O mode between @samp{threads} (the default)
|
2016-01-05 15:33:30 +08:00
|
|
|
and @samp{native} (Linux only).
|
2013-02-08 21:06:13 +08:00
|
|
|
@item --discard=@var{discard}
|
2016-01-05 15:33:32 +08:00
|
|
|
Control whether @dfn{discard} (also known as @dfn{trim} or @dfn{unmap})
|
2016-01-05 15:33:31 +08:00
|
|
|
requests are ignored or passed to the filesystem. @var{discard} is one of
|
|
|
|
@samp{ignore} (or @samp{off}), @samp{unmap} (or @samp{on}). The default is
|
|
|
|
@samp{ignore}.
|
|
|
|
@item --detect-zeroes=@var{detect-zeroes}
|
2016-01-05 15:33:32 +08:00
|
|
|
Control the automatic conversion of plain zero writes by the OS to
|
2016-01-05 15:33:31 +08:00
|
|
|
driver-specific optimized zero write commands. @var{detect-zeroes} is one of
|
|
|
|
@samp{off}, @samp{on} or @samp{unmap}. @samp{unmap}
|
|
|
|
converts a zero write to an unmap operation and can only be used if
|
|
|
|
@var{discard} is set to @samp{unmap}. The default is @samp{off}.
|
2010-03-03 23:18:43 +08:00
|
|
|
@item -c, --connect=@var{dev}
|
2019-01-18 03:36:40 +08:00
|
|
|
Connect @var{filename} to NBD device @var{dev} (Linux only).
|
2008-07-03 18:23:51 +08:00
|
|
|
@item -d, --disconnect
|
2019-01-18 03:36:40 +08:00
|
|
|
Disconnect the device @var{dev} (Linux only).
|
2008-09-23 04:41:57 +08:00
|
|
|
@item -e, --shared=@var{num}
|
2019-01-18 03:36:40 +08:00
|
|
|
Allow up to @var{num} clients to share the device (default
|
|
|
|
@samp{1}). Safe for readers, but for now, consistency is not
|
|
|
|
guaranteed between multiple writers.
|
2008-07-03 21:41:03 +08:00
|
|
|
@item -t, --persistent
|
2019-01-18 03:36:40 +08:00
|
|
|
Don't exit on the last connection.
|
2016-10-15 02:33:03 +08:00
|
|
|
@item -x, --export-name=@var{name}
|
2019-01-18 03:36:40 +08:00
|
|
|
Set the NBD volume export name (default of a zero-length string).
|
2016-10-15 02:33:03 +08:00
|
|
|
@item -D, --description=@var{description}
|
|
|
|
Set the NBD volume export description, as a human-readable
|
2019-01-18 03:36:40 +08:00
|
|
|
string.
|
qemu-nbd: Add --list option
We want to be able to detect whether a given qemu NBD server is
exposing the right export(s) and dirty bitmaps, at least for
regression testing. We could use 'nbd-client -l' from the upstream
NBD project to list exports, but it's annoying to rely on
out-of-tree binaries; furthermore, nbd-client doesn't necessarily
know about all of the qemu NBD extensions. Thus, it is time to add
a new mode to qemu-nbd that merely sniffs all possible information
from the server during handshake phase, then disconnects and dumps
the information.
This patch actually implements --list/-L, while reusing other
options such as --tls-creds for now designating how to connect
as the client (rather than their non-list usage of how to operate
as the server).
I debated about adding this functionality to something akin to
'qemu-img info' - but that tool does not readily lend itself
to connecting to an arbitrary NBD server without also tying to
a specific export (I may, however, still add ImageInfoSpecificNBD
for reporting the bitmaps available when connecting to a single
export). And, while it may feel a bit odd that normally
qemu-nbd is a server but 'qemu-nbd -L' is a client, we are not
really making the qemu-nbd binary that much larger, because
'qemu-nbd -c' has to operate as both server and client
simultaneously across two threads when feeding the kernel module
for /dev/nbdN access.
Sample output:
$ qemu-nbd -L
exports available: 1
export: ''
size: 65536
flags: 0x4ed ( flush fua trim zeroes df cache )
min block: 512
opt block: 4096
max block: 33554432
available meta contexts: 1
base:allocation
Note that the output only lists sizes if the server sent
NBD_FLAG_HAS_FLAGS, because a newstyle server does not give
the size otherwise. It has the side effect that for really
old servers that did not send any flags, the size is not
output even though it was available. However, I'm not too
concerned about that - oldstyle servers are (rightfully)
getting less common to encounter (qemu 3.0 was the last
version where we even serve it), and most existing servers
that still even offer oldstyle negotiation (such as nbdkit)
still send flags (since that was added to the NBD protocol
in 2007 to permit read-only connections).
Not done here, but maybe worth future experiments: capture
the meat of NBDExportInfo into a QAPI struct, and use the
generated QAPI pretty-printers instead of hand-rolling our
output loop. It would also permit us to add a JSON output
mode for machine parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20190117193658.16413-20-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2019-01-18 03:36:56 +08:00
|
|
|
@item -L, --list
|
|
|
|
Connect as a client and list all details about the exports exposed by
|
|
|
|
a remote NBD server. This enables list mode, and is incompatible
|
|
|
|
with options that change behavior related to a specific export (such as
|
|
|
|
@option{--export-name}, @option{--offset}, ...).
|
2016-02-11 02:41:13 +08:00
|
|
|
@item --tls-creds=ID
|
|
|
|
Enable mandatory TLS encryption for the server by setting the ID
|
|
|
|
of the TLS credentials object previously created with the --object
|
qemu-nbd: Add --list option
We want to be able to detect whether a given qemu NBD server is
exposing the right export(s) and dirty bitmaps, at least for
regression testing. We could use 'nbd-client -l' from the upstream
NBD project to list exports, but it's annoying to rely on
out-of-tree binaries; furthermore, nbd-client doesn't necessarily
know about all of the qemu NBD extensions. Thus, it is time to add
a new mode to qemu-nbd that merely sniffs all possible information
from the server during handshake phase, then disconnects and dumps
the information.
This patch actually implements --list/-L, while reusing other
options such as --tls-creds for now designating how to connect
as the client (rather than their non-list usage of how to operate
as the server).
I debated about adding this functionality to something akin to
'qemu-img info' - but that tool does not readily lend itself
to connecting to an arbitrary NBD server without also tying to
a specific export (I may, however, still add ImageInfoSpecificNBD
for reporting the bitmaps available when connecting to a single
export). And, while it may feel a bit odd that normally
qemu-nbd is a server but 'qemu-nbd -L' is a client, we are not
really making the qemu-nbd binary that much larger, because
'qemu-nbd -c' has to operate as both server and client
simultaneously across two threads when feeding the kernel module
for /dev/nbdN access.
Sample output:
$ qemu-nbd -L
exports available: 1
export: ''
size: 65536
flags: 0x4ed ( flush fua trim zeroes df cache )
min block: 512
opt block: 4096
max block: 33554432
available meta contexts: 1
base:allocation
Note that the output only lists sizes if the server sent
NBD_FLAG_HAS_FLAGS, because a newstyle server does not give
the size otherwise. It has the side effect that for really
old servers that did not send any flags, the size is not
output even though it was available. However, I'm not too
concerned about that - oldstyle servers are (rightfully)
getting less common to encounter (qemu 3.0 was the last
version where we even serve it), and most existing servers
that still even offer oldstyle negotiation (such as nbdkit)
still send flags (since that was added to the NBD protocol
in 2007 to permit read-only connections).
Not done here, but maybe worth future experiments: capture
the meat of NBDExportInfo into a QAPI struct, and use the
generated QAPI pretty-printers instead of hand-rolling our
output loop. It would also permit us to add a JSON output
mode for machine parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20190117193658.16413-20-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2019-01-18 03:36:56 +08:00
|
|
|
option; or provide the credentials needed for connecting as a client
|
|
|
|
in list mode.
|
2016-09-29 04:46:42 +08:00
|
|
|
@item --fork
|
|
|
|
Fork off the server process and exit the parent once the server is running.
|
qemu-nbd: add support for authorization of TLS clients
Currently any client which can complete the TLS handshake is able to use
the NBD server. The server admin can turn on the 'verify-peer' option
for the x509 creds to require the client to provide a x509 certificate.
This means the client will have to acquire a certificate from the CA
before they are permitted to use the NBD server. This is still a fairly
low bar to cross.
This adds a '--tls-authz OBJECT-ID' option to the qemu-nbd command which
takes the ID of a previously added 'QAuthZ' object instance. This will
be used to validate the client's x509 distinguished name. Clients
failing the authorization check will not be permitted to use the NBD
server.
For example to setup authorization that only allows connection from a client
whose x509 certificate distinguished name is
CN=laptop.example.com,O=Example Org,L=London,ST=London,C=GB
escape the commas in the name and use:
qemu-nbd --object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
--object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,\
O=Example Org,,L=London,,ST=London,,C=GB' \
--tls-creds tls0 \
--tls-authz authz0 \
....other qemu-nbd args...
NB: a real shell command line would not have leading whitespace after
the line continuation, it is just included here for clarity.
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20190227162035.18543-2-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: split long line in --help text, tweak 233 to show that whitespace
after ,, in identity= portion is actually okay]
Signed-off-by: Eric Blake <eblake@redhat.com>
2019-02-28 00:20:33 +08:00
|
|
|
@item --tls-authz=ID
|
|
|
|
Specify the ID of a qauthz object previously created with the
|
|
|
|
--object option. This will be used to authorize connecting users
|
|
|
|
against their x509 distinguished name.
|
2008-05-28 05:13:40 +08:00
|
|
|
@item -v, --verbose
|
2019-01-18 03:36:40 +08:00
|
|
|
Display extra debugging information.
|
2008-05-28 05:13:40 +08:00
|
|
|
@item -h, --help
|
2019-01-18 03:36:40 +08:00
|
|
|
Display this help and exit.
|
2008-05-28 05:13:40 +08:00
|
|
|
@item -V, --version
|
2019-01-18 03:36:40 +08:00
|
|
|
Display version information and exit.
|
2016-06-17 22:44:12 +08:00
|
|
|
@item -T, --trace [[enable=]@var{pattern}][,events=@var{file}][,file=@var{file}]
|
|
|
|
@findex --trace
|
|
|
|
@include qemu-option-trace.texi
|
2008-05-28 05:13:40 +08:00
|
|
|
@end table
|
|
|
|
|
|
|
|
@c man end
|
|
|
|
|
2019-01-18 03:36:40 +08:00
|
|
|
@c man begin EXAMPLES
|
|
|
|
Start a server listening on port 10809 that exposes only the
|
|
|
|
guest-visible contents of a qcow2 file, with no TLS encryption, and
|
|
|
|
with the default export name (an empty string). The command is
|
|
|
|
one-shot, and will block until the first successful client
|
|
|
|
disconnects:
|
|
|
|
|
|
|
|
@example
|
|
|
|
qemu-nbd -f qcow2 file.qcow2
|
|
|
|
@end example
|
|
|
|
|
|
|
|
Start a long-running server listening with encryption on port 10810,
|
qemu-nbd: add support for authorization of TLS clients
Currently any client which can complete the TLS handshake is able to use
the NBD server. The server admin can turn on the 'verify-peer' option
for the x509 creds to require the client to provide a x509 certificate.
This means the client will have to acquire a certificate from the CA
before they are permitted to use the NBD server. This is still a fairly
low bar to cross.
This adds a '--tls-authz OBJECT-ID' option to the qemu-nbd command which
takes the ID of a previously added 'QAuthZ' object instance. This will
be used to validate the client's x509 distinguished name. Clients
failing the authorization check will not be permitted to use the NBD
server.
For example to setup authorization that only allows connection from a client
whose x509 certificate distinguished name is
CN=laptop.example.com,O=Example Org,L=London,ST=London,C=GB
escape the commas in the name and use:
qemu-nbd --object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
--object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,\
O=Example Org,,L=London,,ST=London,,C=GB' \
--tls-creds tls0 \
--tls-authz authz0 \
....other qemu-nbd args...
NB: a real shell command line would not have leading whitespace after
the line continuation, it is just included here for clarity.
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20190227162035.18543-2-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: split long line in --help text, tweak 233 to show that whitespace
after ,, in identity= portion is actually okay]
Signed-off-by: Eric Blake <eblake@redhat.com>
2019-02-28 00:20:33 +08:00
|
|
|
and whitelist clients with a specific X.509 certificate to connect to
|
2019-01-18 03:36:40 +08:00
|
|
|
a 1 megabyte subset of a raw file, using the export name 'subset':
|
|
|
|
|
|
|
|
@example
|
|
|
|
qemu-nbd \
|
|
|
|
--object tls-creds-x509,id=tls0,endpoint=server,dir=/path/to/qemutls \
|
qemu-nbd: add support for authorization of TLS clients
Currently any client which can complete the TLS handshake is able to use
the NBD server. The server admin can turn on the 'verify-peer' option
for the x509 creds to require the client to provide a x509 certificate.
This means the client will have to acquire a certificate from the CA
before they are permitted to use the NBD server. This is still a fairly
low bar to cross.
This adds a '--tls-authz OBJECT-ID' option to the qemu-nbd command which
takes the ID of a previously added 'QAuthZ' object instance. This will
be used to validate the client's x509 distinguished name. Clients
failing the authorization check will not be permitted to use the NBD
server.
For example to setup authorization that only allows connection from a client
whose x509 certificate distinguished name is
CN=laptop.example.com,O=Example Org,L=London,ST=London,C=GB
escape the commas in the name and use:
qemu-nbd --object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
endpoint=server,verify-peer=yes \
--object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,\
O=Example Org,,L=London,,ST=London,,C=GB' \
--tls-creds tls0 \
--tls-authz authz0 \
....other qemu-nbd args...
NB: a real shell command line would not have leading whitespace after
the line continuation, it is just included here for clarity.
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Message-Id: <20190227162035.18543-2-berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: split long line in --help text, tweak 233 to show that whitespace
after ,, in identity= portion is actually okay]
Signed-off-by: Eric Blake <eblake@redhat.com>
2019-02-28 00:20:33 +08:00
|
|
|
--object 'authz-simple,id=auth0,identity=CN=laptop.example.com,,\
|
|
|
|
O=Example Org,,L=London,,ST=London,,C=GB' \
|
|
|
|
--tls-creds tls0 --tls-authz auth0 \
|
|
|
|
-t -x subset -p 10810 \
|
2019-01-18 03:36:40 +08:00
|
|
|
--image-opts driver=raw,offset=1M,size=1M,file.driver=file,file.filename=file.raw
|
|
|
|
@end example
|
|
|
|
|
|
|
|
Serve a read-only copy of just the first MBR partition of a guest
|
|
|
|
image over a Unix socket with as many as 5 simultaneous readers, with
|
|
|
|
a persistent process forked as a daemon:
|
|
|
|
|
|
|
|
@example
|
|
|
|
qemu-nbd --fork --persistent --shared=5 --socket=/path/to/sock \
|
|
|
|
--partition=1 --read-only --format=qcow2 file.qcow2
|
|
|
|
@end example
|
|
|
|
|
|
|
|
Expose the guest-visible contents of a qcow2 file via a block device
|
|
|
|
/dev/nbd0 (and possibly creating /dev/nbd0p1 and friends for
|
|
|
|
partitions found within), then disconnect the device when done.
|
|
|
|
Access to bind qemu-nbd to an /dev/nbd device generally requires root
|
|
|
|
privileges, and may also require the execution of @code{modprobe nbd}
|
|
|
|
to enable the kernel NBD client module. @emph{CAUTION}: Do not use
|
|
|
|
this method to mount filesystems from an untrusted guest image - a
|
|
|
|
malicious guest may have prepared the image to attempt to trigger
|
|
|
|
kernel bugs in partition probing or file system mounting.
|
|
|
|
|
|
|
|
@example
|
|
|
|
qemu-nbd -c /dev/nbd0 -f qcow2 file.qcow2
|
|
|
|
qemu-nbd -d /dev/nbd0
|
|
|
|
@end example
|
|
|
|
|
qemu-nbd: Add --list option
We want to be able to detect whether a given qemu NBD server is
exposing the right export(s) and dirty bitmaps, at least for
regression testing. We could use 'nbd-client -l' from the upstream
NBD project to list exports, but it's annoying to rely on
out-of-tree binaries; furthermore, nbd-client doesn't necessarily
know about all of the qemu NBD extensions. Thus, it is time to add
a new mode to qemu-nbd that merely sniffs all possible information
from the server during handshake phase, then disconnects and dumps
the information.
This patch actually implements --list/-L, while reusing other
options such as --tls-creds for now designating how to connect
as the client (rather than their non-list usage of how to operate
as the server).
I debated about adding this functionality to something akin to
'qemu-img info' - but that tool does not readily lend itself
to connecting to an arbitrary NBD server without also tying to
a specific export (I may, however, still add ImageInfoSpecificNBD
for reporting the bitmaps available when connecting to a single
export). And, while it may feel a bit odd that normally
qemu-nbd is a server but 'qemu-nbd -L' is a client, we are not
really making the qemu-nbd binary that much larger, because
'qemu-nbd -c' has to operate as both server and client
simultaneously across two threads when feeding the kernel module
for /dev/nbdN access.
Sample output:
$ qemu-nbd -L
exports available: 1
export: ''
size: 65536
flags: 0x4ed ( flush fua trim zeroes df cache )
min block: 512
opt block: 4096
max block: 33554432
available meta contexts: 1
base:allocation
Note that the output only lists sizes if the server sent
NBD_FLAG_HAS_FLAGS, because a newstyle server does not give
the size otherwise. It has the side effect that for really
old servers that did not send any flags, the size is not
output even though it was available. However, I'm not too
concerned about that - oldstyle servers are (rightfully)
getting less common to encounter (qemu 3.0 was the last
version where we even serve it), and most existing servers
that still even offer oldstyle negotiation (such as nbdkit)
still send flags (since that was added to the NBD protocol
in 2007 to permit read-only connections).
Not done here, but maybe worth future experiments: capture
the meat of NBDExportInfo into a QAPI struct, and use the
generated QAPI pretty-printers instead of hand-rolling our
output loop. It would also permit us to add a JSON output
mode for machine parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20190117193658.16413-20-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2019-01-18 03:36:56 +08:00
|
|
|
Query a remote server to see details about what export(s) it is
|
|
|
|
serving on port 10809, and authenticating via PSK:
|
|
|
|
|
|
|
|
@example
|
|
|
|
qemu-nbd \
|
|
|
|
--object tls-creds-psk,id=tls0,dir=/tmp/keys,username=eblake,endpoint=client \
|
|
|
|
--tls-creds tls0 -L -b remote.example.com
|
|
|
|
@end example
|
|
|
|
|
2019-01-18 03:36:40 +08:00
|
|
|
@c man end
|
|
|
|
|
2008-05-28 05:13:40 +08:00
|
|
|
@ignore
|
|
|
|
|
|
|
|
@setfilename qemu-nbd
|
|
|
|
@settitle QEMU Disk Network Block Device Server
|
|
|
|
|
|
|
|
@c man begin AUTHOR
|
|
|
|
Copyright (C) 2006 Anthony Liguori <anthony@codemonkey.ws>.
|
|
|
|
This is free software; see the source for copying conditions. There is NO
|
|
|
|
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
@c man end
|
|
|
|
|
|
|
|
@c man begin SEEALSO
|
2016-01-05 15:33:31 +08:00
|
|
|
qemu(1), qemu-img(1)
|
2008-05-28 05:13:40 +08:00
|
|
|
@c man end
|
|
|
|
|
|
|
|
@end ignore
|