"Denis V. Lunev" <[email protected]> writes: > 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. > > Add ImageInfoSpecificParallels with the bitmaps and their granularity, > as qcow2 reports the contents of its bitmap directory: > > Format specific information: > bitmaps: > [0]: > name: b2c9e1a4-5d3f-4e8b-9a7c-6f0d1e2b3a45 > granularity: 65536 > > The list is built from the bitmaps loaded at open time rather than from > a second pass over the Format Extension, as every bitmap the extension > carries is loaded and marked persistent there. On a node which is open > that also covers a bitmap which was created but not stored yet, which is > what the field says: qemu-img info opens the image on its own, so there > the two are the same thing.
The last sentence confuses me. > An image with no bitmaps leaves the structure empty, and > bdrv_image_info_specific_dump() prints nothing for an empty one, so the > output for such an image does not change. Output of what? I guess it's "info block" and "qemu-img info", because these call bdrv_image_info_specific_dump(). > Cc: Stefan Hajnoczi <[email protected]> > Cc: Eric Blake <[email protected]> > Cc: Markus Armbruster <[email protected]> > Signed-off-by: Denis V. Lunev <[email protected]> [...] > diff --git a/qapi/block-core.json b/qapi/block-core.json > index 1f87b07850..4bc8b45efe 100644 > --- a/qapi/block-core.json > +++ b/qapi/block-core.json > @@ -200,7 +200,7 @@ > # Since: 1.7 > ## > { 'enum': 'ImageInfoSpecificKind', > - 'data': [ 'qcow2', 'vmdk', 'luks', 'rbd', 'file' ] } > + 'data': [ 'qcow2', 'vmdk', 'luks', 'rbd', 'file', 'parallels' ] } > > ## > # @ImageInfoSpecificQCow2Wrapper: > @@ -255,6 +255,41 @@ > { 'struct': 'ImageInfoSpecificFileWrapper', > 'data': { 'data': 'ImageInfoSpecificFile' } } > > +## > +# @ParallelsBitmapInfo: > +# > +# Parallels dirty bitmap information. > +# > +# @name: the name of the bitmap > +# > +# @granularity: granularity of the bitmap in bytes > +# > +# Since: 11.2 > +## > +{ 'struct': 'ParallelsBitmapInfo', > + 'data': { 'name': 'str', 'granularity': 'uint32' } } > + > +## > +# @ImageInfoSpecificParallels: > +# > +# @bitmaps: A list of the persistent dirty bitmaps of the image, > +# including the ones which are not written out yet Pardon my ignorance... Is "not written out yet" relevant to a user / management application? ImageInfoSpecificQCow2 also has a @bitmaps member. Its documentation is # @bitmaps: A list of qcow2 bitmap details (since 4.0) Are these "persistent dirty bitmaps" as well, or something else? > +# > +# Since: 11.2 > +## > +{ 'struct': 'ImageInfoSpecificParallels', > + 'data': { '*bitmaps': ['ParallelsBitmapInfo'] } } Please put these right after ImageInfoSpecificFile to preserve the existing order of things: All the ImageInfoSpecificFOO in order of ImageInfoSpecificKind members ImageInfoSpecificKind All the ImageInfoSpecificFOOWrapper in order of ImageInfoSpecificKind members ImageInfoSpecific > + > +## > +# @ImageInfoSpecificParallelsWrapper: > +# > +# @data: image information specific to Parallels > +# > +# Since: 11.2 > +## > +{ 'struct': 'ImageInfoSpecificParallelsWrapper', > + 'data': { 'data': 'ImageInfoSpecificParallels' } } > + > ## > # @ImageInfoSpecific: > # > @@ -273,7 +308,8 @@ > 'vmdk': 'ImageInfoSpecificVmdkWrapper', > 'luks': 'ImageInfoSpecificLUKSWrapper', > 'rbd': 'ImageInfoSpecificRbdWrapper', > - 'file': 'ImageInfoSpecificFileWrapper' > + 'file': 'ImageInfoSpecificFileWrapper', > + 'parallels': 'ImageInfoSpecificParallelsWrapper' > } } > > ## [...]
