On 8/25/26 11:10, Markus Armbruster wrote: > "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(). For the image (BDS) without dirty bitmaps the output of 'qemu-img info' would be the same as with and without a patch.
>> 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? This means that the image on disk could contains bitmaps A and B while backup software has added bitmap C to BDS. The query will return A, B, C. This is same as for QCOW2. > 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? same, as above >> +# >> +# 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 clear, will do >> + >> +## >> +# @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' >> } } >> >> ## > [...] > Thank you, Den
