Re: [PATCH v8 1/3] parallels: report the stored dirty bitmaps in qemu-img info

[Eric Blake <eblake@redhat.com>]

On Sun, Sep 13, 2026 at 09:52:59PM +0200, Denis V. Lunev wrote:
> From: Denis V. Lunev <den@openvz.org>
> 
> 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 <stefanha@redhat.com>
> Cc: Eric Blake <eblake@redhat.com>
> Cc: Markus Armbruster <armbru@redhat.com>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> ---
>  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