On Sun, Sep 13, 2026 at 09:52:59PM +0200, Denis V. Lunev wrote:
> From: Denis V. Lunev <[email protected]>
>
> Nothing tells which persistent bitmaps an image carries. qemu-img info
> says nothing about them, and the only other way to see one is to export
> the image over NBD and ask for a bitmap by name, which needs the name
> beforehand.
I would amend that statement, "s/an image/a parallels image/"; because
existing 'qemu-img info' definitely tells you what bitmaps a qcow2
image has:
$ qemu-img create -f qcow2 base.qcow2 100M
Formatting 'base.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off
compression_type=zlib size=104857600 lazy_refcounts=off refcount_bits=16
$ qemu-img bitmap --add -f qcow2 base.qcow2 bm1
$ qemu-img bitmap --add -f qcow2 base.qcow2 bm2
$ qemu-img info base.qcow2
image: base.qcow2
file format: qcow2
virtual size: 100 MiB (104857600 bytes)
disk size: 220 KiB
cluster_size: 65536
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: false
bitmaps:
[0]:
flags:
[0]: auto
name: bm1
granularity: 65536
[1]:
flags:
[0]: auto
name: bm2
granularity: 65536
refcount bits: 16
...
Also, the NBD protocol indeed allows a client to query what
metacontexts an image supports, which can be used to expose bitmaps;
and both 'qemu-nbd -L' and libnbd's 'nbdinfo' are happy to read that
information. But, at present, qemu-nbd limits us to exposing that on
a per-bitmap basis, rather than having an easy way to export all
bitmaps at once. For example,
$ qemu-nbd -L
exports available: 1
export: ''
...
available meta contexts: 4
base:allocation
qemu:allocation-depth
qemu:dirty-bitmap:bm2
qemu:dirty-bitmap:bm1
$ nbdinfo nbd://localhost
protocol: newstyle-fixed without TLS, using extended packets
export="":
...
contexts:
base:allocation
qemu:allocation-depth
qemu:dirty-bitmap:bm2
qemu:dirty-bitmap:bm1
...
So I will probably submit a patch to add a command-line flag to
qemu-nbd to expose all known bitmaps without having to do a -B option
per name, on top of this series.
>
> Add ImageInfoSpecificParallels with the bitmaps and their granularity,
> in the same way as qcow2 reports the contents of its bitmap directory:
>
> Format specific information:
> bitmaps:
> [0]:
> name: b2c9e1a4-5d3f-4e8b-9a7c-6f0d1e2b3a45
> granularity: 65536
>
> For running VM process the list is built on the fly from in-memory
> list. This is the best we can do. FormatExtension could be dead in
> the image while VMs are running as all bitmaps are cleared on
> non-clean VM stop.
>
> A bitmap of an image which was not closed correctly is inconsistent
> and can not be used. Report that as well, the way qcow2 reports its
> in-use flag, so such a bitmap is not listed as a valid one.
>
> The section is left empty for an image with no persistent dirty
> bitmaps, and an empty section is not printed, so the human readable
> output of "qemu-img info" and "info block" is unchanged.
>
> Cc: Stefan Hajnoczi <[email protected]>
> Cc: Eric Blake <[email protected]>
> Cc: Markus Armbruster <[email protected]>
> Signed-off-by: Denis V. Lunev <[email protected]>
> ---
> block/parallels-ext.c | 26 +++++++++++
> block/parallels.c | 20 +++++++++
> block/parallels.h | 3 ++
> qapi/block-core.json | 45 ++++++++++++++++++-
> tests/qemu-iotests/tests/parallels-checks | 6 +++
> tests/qemu-iotests/tests/parallels-checks.out | 19 ++++++++
> 6 files changed, 117 insertions(+), 2 deletions(-)
>
> +++ b/qapi/block-core.json
> +##
> +# @ParallelsBitmapInfo:
> +#
> +# Parallels bitmap information.
> +#
> +# @name: the name of the bitmap
> +#
> +# @granularity: granularity of the bitmap in bytes
> +#
> +# @inconsistent: true if the bitmap is in an inconsistent state and
> +# cannot be used
> +#
> +# Since: 11.2
> +##
> +{ 'struct': 'ParallelsBitmapInfo',
> + 'data': { 'name': 'str', 'granularity': 'uint32',
> + '*inconsistent': 'bool' } }
Should @inconsistent mention that it is default false, since it is
listed as optional? Or is there any reason why we should not output an
explicit value of false and make the field non-optional?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
