Adding qemu-block for the cover letter (not sure how I missed that the
first time).
On Mon, May 15, 2023 at 02:53:29PM -0500, Eric Blake wrote:
>
> v2 was here:
> https://lists.gnu.org/archive/html/qemu-devel/2022-11/msg02340.html
>
> Since then:
> - upstream NBD has accepted the extension
Allow a client to request a subset of negotiated meta contexts. For
example, a client may ask to use a single connection to learn about
both block status and dirty bitmaps, but where the dirty bitmap
queries only need to be performed on a subset of the disk; forcing the
server to compute that
Because we use NBD_CMD_FLAG_REQ_ONE with NBD_CMD_BLOCK_STATUS, a
client in narrow mode should not be able to provoke a server into
sending a block status result larger than the client's 32-bit request.
But in extended mode, a 64-bit status request must be able to handle a
64-bit status result,
All the pieces are in place for a client to finally request extended
headers. Note that we must not request extended headers when qemu-nbd
is used to connect to the kernel module (as nbd.ko does not expect
them), but there is no harm in all other clients requesting them.
Extended headers are not
The next commit will add support for the new addition of
NBD_CMD_FLAG_PAYLOAD during NBD_CMD_BLOCK_STATUS, where the client can
request that the server only return a subset of negotiated contexts,
rather than all contexts. To make that task easier, this patch
populates the list of contexts to
Time to support clients that request extended headers. Now we can
finally reach the code added across several previous patches.
Even though the NBD spec has been altered to allow us to accept
NBD_CMD_READ larger than the max payload size (provided our response
is a hole or broken up over more
Update the client code to be able to send an extended request, and
parse an extended header from the server. Note that since we reject
any structured reply with a too-large payload, we can always normalize
a valid header back into the compact form, so that the caller need not
deal with two
The NBD spec states that if the client negotiates extended headers,
the server must avoid NBD_REPLY_TYPE_BLOCK_STATUS and instead use
NBD_REPLY_TYPE_BLOCK_STATUS_EXT which supports 64-bit lengths, even if
the reply does not need more than 32 bits. As of this patch,
client->header_style is still
Part of NBD's 64-bit headers extension involves passing the client's
requested offset back as part of the reply header (one reason for this
change: converting absolute offsets stored in
NBD_REPLY_TYPE_OFFSET_DATA to relative offsets within the buffer is
easier if the absolute offset of the buffer
v2 was here:
https://lists.gnu.org/archive/html/qemu-devel/2022-11/msg02340.html
Since then:
- upstream NBD has accepted the extension on a branch; once multiple
implementations interoperate based on that spec, it will be promoted
to mainline (my plan: qemu with this series, libnbd nearly
Widen the length field of NBDRequest to 64-bits, although we can
assert that all current uses are still under 32 bits. Move the
request magic number to nbd.h, to live alongside the reply magic
number. Convert 'bool structured_reply' into a tri-state enum that
will eventually track whether the
Assigning strlen() to a uint32_t and then asserting that it isn't too
large doesn't catch the case of an input string 4G in length.
Thankfully, the incoming strings can never be that large: if the
export name or query is reflecting a string the client got from the
server, we already guarantee that
Upstream NBD now documents[1] an extension that supports 64-bit effect
lengths in requests. As part of that extension, the size of the reply
headers will change in order to permit a 64-bit length in the reply
for symmetry[2]. Additionally, where the reply header is currently
16 bytes for simple
Upcoming additions to support NBD 64-bit effect lengths allow for the
possibility to distinguish between payload length (capped at 32M) and
effect length (up to 63 bits). Without that extension, only the
NBD_CMD_WRITE request has a payload; but with the extension, it makes
sense to allow at least
Our existing use of structured replies either reads into a qiov capped
at 32M (NBD_CMD_READ) or caps allocation to 1000 bytes (see
NBD_MAX_MALLOC_PAYLOAD in block/nbd.c). But the existing length
checks are rather late; if we encounter a buggy (or malicious) server
that sends a super-large payload
Add the constants and structs necessary for later patches to start
implementing the NBD_OPT_EXTENDED_HEADERS extension in both the client
and server, matching recent commit e6f3b94a934] in the upstream nbd
project. This patch does not change any existing behavior, but merely
sets the stage.
This
In the LUKS-on-LVM conversion test, repeat the null conversion with such
"--key" options that exercise the recent "/dev/mapper/VG-LV" ->
"/dev/VG/LV" translation (unescaping) from libguestfs-common.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168506
Signed-off-by: Laszlo Ersek
---
https://bugzilla.redhat.com/show_bug.cgi?id=2168506
This small set covers the new /dev/mapper/VG-LV "--key" ID format in the
virt-v2v LUKS-on-LVM conversion test. It depends on:
[libguestfs-common PATCH 0/2] recognize "/dev/mapper/VG-LV" with "--key"
Message-Id:
In preparation for a subsequent patch, rename "VG" to "Volume-Group", and
"LV" to "Logical-Volume-", in the LUKS-on-LVM conversion test.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168506
Signed-off-by: Laszlo Ersek
---
test-data/phony-guests/make-fedora-img.pl | 30
On Mon, May 15, 2023 at 07:22:28PM +0200, Laszlo Ersek wrote:
> Hi Rich,
>
> do we expect "make check-valgrind" to succeed in virt-v2v at the moment
> (at commit e83de8abe6c5)? I see there's a "valgrind-suppressions" file
> in the project root, but "make check-valgrind" still fails for me, with
>
https://bugzilla.redhat.com/show_bug.cgi?id=2168506
The commit message of the second patch explains the idea.
The test suites in libguestfs, guestfs-tools and virt-v2v will have to
be extended so they cover this feature; I'm soon going to post the
virt-v2v update. I plan to cover the libguestfs
Introduce unescape_device_mapper_lvm() for turning
/dev/mapper/VG-LV
key IDs into
/dev/VG/LV
ones, unescaping doubled hyphens to single hyphens in both VG and LV in
the process. Libguestfs uses the /dev/VG/LV format internally, for
identifying devices, but the user might want to specify
The key_store_import_key() function is called from both C-language
utilities -- via key_store_add_from_selector() -- and OCaml-language ones
-- via guestfs_int_mllib_inspect_decrypt(). We currently declare the
function's second parameter as
const struct key_store_key *key
That is however a
Hi Rich,
do we expect "make check-valgrind" to succeed in virt-v2v at the moment
(at commit e83de8abe6c5)? I see there's a "valgrind-suppressions" file
in the project root, but "make check-valgrind" still fails for me, with
numerous errors.
I'm attaching the test suite log. (Compare
On 5/15/23 13:21, Richard W.M. Jones wrote:
>
> It all looks fine to me, barring comments that Eric has already made,
> so ACK series.
Thank you both for the reviews; merged as commit range
d2d214c4e161..96fdc62ad59d.
Phew. :)
Laszlo
___
Libguestfs
It all looks fine to me, barring comments that Eric has already made,
so ACK series.
Thanks,
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with
26 matches
Mail list logo
