On 8/27/26 10:29, Markus Armbruster wrote: > "Denis V. Lunev" <[email protected]> writes: > >> 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. > Suggest to clarify 'the output' to something like 'the output of > "qemu-img info" and "info block"'. OK. Clear.
>>>> 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. > Will bitmap C be written to the image, and when? On close. Same as QCOW2. This is done usually on VM stop. >>> 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 > If they're basically the same, then their documentation should be > basically the same. OK.
