[v8,0/2] qemu-img info lists bitmap directory entries

Message

Andrey Shinkevich Jan. 28, 2019, 6:40 p.m. UTC

Here is the update for the bitmap extension of the qcow2 specific
information as the output of the 'qemu-img info' command.
The version #7 was in email with the message ID:
<[e-mail]>

v8:
The output benchmark files for the qemu-iotests, namely 060, 065 082, 198
and 206, were modified to show the bitmap extension for the qemu specific
information. A new test file 239 was added to the test set that checks the
output for the fields of the bitmap section.
The backward compatibility of the output for images of the version 2
of qcow2 was added.

v7:
A description was added to the function qcow2_get_bitmap_info_list().
In the function qcow2_get_specific_info(), the comment was modified
so that we ignore any error in obtaining the list of bitmaps to
pass the rest of QCOW2 specific information to a caller.

v6:
'[PATCH v6] qemu-img info lists bitmap directory entries'.
The error handling logic for the bitmaps empty list was reversed.

v5:
'[PATCH v5] qemu-img info lists bitmap directory entries'.
The error handling logic for the bitmaps empty list was fixed and documented.

v4:
'[PATCH v4] qemu-img info lists bitmap directory entries'.
Unknown flags are checked with the mask BME_RESERVED_FLAGS.
The code minor refactoring was made.

v3:
'[PATCH v3] qemu-img info lists bitmap directory entries'.
Now, qcow2_get_bitmap_info_list() is invoked under the condition of QCOW
version #3 to avoid memory leaks in case of QCOW version #2.
Furthermore, qcow2_get_bitmap_info_list() checks the number of existing bitmaps.
So, if no bitmap exists, no bitmap error message is printed in the output.
The data type of the bitmap 'granularity' parameter was left as 'uint32'
because bitmap_list_load() returns error if granularity_bits is grater than 31.

v2:
'[PATCH v2] qemu-img info lists bitmap directory entries'.
The targeted version of the release at 'Since' word of the comments to the new
structures changed to 4.0 in the file qapi/block-core.json.
A comment to the 'bitmaps' new member was supplied.
The 'unknown flags' parameter was introduced to indicate presence of QCOW2
bitmap unknown flags, if any.
The word 'dirty' was removed from the code and from the comments as we list all
the bitmaps.
The 'bitmaps' printed parameter was removed for the release versions earlier
than 3.x.
The example of the output was moved above the 'Signed-off-by' line.

The first version was '[PATCH] qemu-img info lists bitmap directory entries'.

Andrey Shinkevich (2):
  qemu-img info lists bitmap directory entries
  qemu-img info: bitmaps extension new test 239

 block/qapi.c               |  6 +++++
 block/qcow2-bitmap.c       | 64 ++++++++++++++++++++++++++++++++++++++++++++++
 block/qcow2.c              | 13 ++++++++++
 block/qcow2.h              |  2 ++
 qapi/block-core.json       | 42 +++++++++++++++++++++++++++++-
 tests/qemu-iotests/060.out |  1 +
 tests/qemu-iotests/065     | 16 ++++++------
 tests/qemu-iotests/082.out |  7 +++++
 tests/qemu-iotests/198.out |  2 ++
 tests/qemu-iotests/206.out |  5 ++++
 tests/qemu-iotests/239     | 58 +++++++++++++++++++++++++++++++++++++++++
 tests/qemu-iotests/239.out | 33 ++++++++++++++++++++++++
 tests/qemu-iotests/group   |  1 +
 13 files changed, 241 insertions(+), 9 deletions(-)
 create mode 100755 tests/qemu-iotests/239
 create mode 100644 tests/qemu-iotests/239.out

Comments

Eric Blake Jan. 30, 2019, 4:01 a.m. UTC | #1

On 1/28/19 12:40 PM, Andrey Shinkevich wrote:
> Here is the update for the bitmap extension of the qcow2 specific
> information as the output of the 'qemu-img info' command.
> The version #7 was in email with the message ID:
> <[e-mail]>
> 
> v8:
> The output benchmark files for the qemu-iotests, namely 060, 065 082, 198
> and 206, were modified to show the bitmap extension for the qemu specific
> information. A new test file 239 was added to the test set that checks the
> output for the fields of the bitmap section.
> The backward compatibility of the output for images of the version 2
> of qcow2 was added.

So, I'm trying to test this, and I've discovered something rather
annoying about persistent snapshots: they DON'T get written to disk
until the qemu process exits.  In other words, even after creating a
persistent bitmap via QMP (I'm trying to debug my libvirt API for
incremental snapshots, so I did this via 'virsh snapshot-create-as $dom
name', but it boils down to a QMP transaction with
'block-dirty-bitmap-add' as one of the commands), running:

$ qemu-img info -U Active1.qcow2

shows
    bitmaps:
    refcount bits: 16

for as long as the qemu process is running. What does it take to force a
qcow2 image to write out its current set of known bitmaps to disk, even
if they are known to be potentially dirty? Should it happen any time we
flush L1/L2/refcount tables?  On a periodic but slow timer (say once
every 5 minutes)? Other ideas?  I know we don't want to be flushing the
full bitmap contents on every change to the in-memory internal bitmap,
but meta-changes (such as adding a bitmap) seem like the sort of thing
where it's worth flushing the qcow2 file; particularly when adding the
bitmap via QMP 'transaction' which goes to the bother of flushing all
pending I/O in order to properly roll back on failure (which means on
success, it would be nice for the new bitmap name to show up in the
qcow2 header, even if the contents of the bitmap are not up-to-date).

Vladimir Sementsov-Ogievskiy Jan. 30, 2019, 8 a.m. UTC | #2

30.01.2019 7:01, Eric Blake wrote:
> On 1/28/19 12:40 PM, Andrey Shinkevich wrote:
>> Here is the update for the bitmap extension of the qcow2 specific
>> information as the output of the 'qemu-img info' command.
>> The version #7 was in email with the message ID:
>> <[e-mail]>
>>
>> v8:
>> The output benchmark files for the qemu-iotests, namely 060, 065 082, 198
>> and 206, were modified to show the bitmap extension for the qemu specific
>> information. A new test file 239 was added to the test set that checks the
>> output for the fields of the bitmap section.
>> The backward compatibility of the output for images of the version 2
>> of qcow2 was added.
> 
> So, I'm trying to test this, and I've discovered something rather
> annoying about persistent snapshots: they DON'T get written to disk
> until the qemu process exits.  In other words, even after creating a
> persistent bitmap via QMP (I'm trying to debug my libvirt API for
> incremental snapshots, so I did this via 'virsh snapshot-create-as $dom
> name', but it boils down to a QMP transaction with
> 'block-dirty-bitmap-add' as one of the commands), running:
> 
> $ qemu-img info -U Active1.qcow2
> 
> shows
>      bitmaps:
>      refcount bits: 16
> 
> for as long as the qemu process is running. What does it take to force a
> qcow2 image to write out its current set of known bitmaps to disk, even
> if they are known to be potentially dirty? Should it happen any time we
> flush L1/L2/refcount tables?  On a periodic but slow timer (say once
> every 5 minutes)? Other ideas?  I know we don't want to be flushing the
> full bitmap contents on every change to the in-memory internal bitmap,
> but meta-changes (such as adding a bitmap) seem like the sort of thing
> where it's worth flushing the qcow2 file; particularly when adding the
> bitmap via QMP 'transaction' which goes to the bother of flushing all
> pending I/O in order to properly roll back on failure (which means on
> success, it would be nice for the new bitmap name to show up in the
> qcow2 header, even if the contents of the bitmap are not up-to-date).
> 

But what is the benefit of it, except qemu-img info with --force-share option,
which of course is not guaranteed to show valid metadata?

While qemu is running valid way to obtain info is qmp. Do libvirt call qemu-img
--fore-share?

Eric Blake Jan. 30, 2019, 12:43 p.m. UTC | #3

On 1/30/19 2:00 AM, Vladimir Sementsov-Ogievskiy wrote:

>> So, I'm trying to test this, and I've discovered something rather
>> annoying about persistent snapshots: they DON'T get written to disk
>> until the qemu process exits.  In other words, even after creating a
>> persistent bitmap via QMP (I'm trying to debug my libvirt API for
>> incremental snapshots, so I did this via 'virsh snapshot-create-as $dom
>> name', but it boils down to a QMP transaction with
>> 'block-dirty-bitmap-add' as one of the commands), running:
>>
>> $ qemu-img info -U Active1.qcow2
>>
>> shows
>>      bitmaps:
>>      refcount bits: 16
>>
>> for as long as the qemu process is running.

> 
> But what is the benefit of it, except qemu-img info with --force-share option,
> which of course is not guaranteed to show valid metadata?
> 
> While qemu is running valid way to obtain info is qmp. Do libvirt call qemu-img
> --fore-share?

You're right that libvirt will be using QMP and not qemu-img. But that
does not prevent other clients from using qemu-img on a file, regardless
of whether the file is in use by a guest. There's also the argument that
if qemu dies suddenly (most likely due to a bug or to a host being
fenced), knowing what bitmaps were present in the image is better than
having nothing at all (but conversely, if qemu dies suddenly, you are
likely missing the bitmap data for the most recent changes, so even if
disabled bitmaps are flushed and no longer marked in-use, they still
won't be sufficient to allow an incremental backup, and a full backup
will be necessary regardless of how much or little bitmap information
got persisted).

While you're right that --force-share is not required to show up-to-date
metadata, it also is not required to show nothing at all.  And at least
knowing that a persistent bitmap is associated with a qcow2 file may
make other things obvious - such as the fact that the image can't be
resized (until we implement the functionality to support resize and
bitmaps in the same image).

Vladimir Sementsov-Ogievskiy Jan. 30, 2019, 1:28 p.m. UTC | #4

30.01.2019 15:43, Eric Blake wrote:
> On 1/30/19 2:00 AM, Vladimir Sementsov-Ogievskiy wrote:
> 
>>> So, I'm trying to test this, and I've discovered something rather
>>> annoying about persistent snapshots: they DON'T get written to disk
>>> until the qemu process exits.  In other words, even after creating a
>>> persistent bitmap via QMP (I'm trying to debug my libvirt API for
>>> incremental snapshots, so I did this via 'virsh snapshot-create-as $dom
>>> name', but it boils down to a QMP transaction with
>>> 'block-dirty-bitmap-add' as one of the commands), running:
>>>
>>> $ qemu-img info -U Active1.qcow2
>>>
>>> shows
>>>       bitmaps:
>>>       refcount bits: 16
>>>
>>> for as long as the qemu process is running.
> 
>>
>> But what is the benefit of it, except qemu-img info with --force-share option,
>> which of course is not guaranteed to show valid metadata?
>>
>> While qemu is running valid way to obtain info is qmp. Do libvirt call qemu-img
>> --fore-share?
> 
> You're right that libvirt will be using QMP and not qemu-img. But that
> does not prevent other clients from using qemu-img on a file

I just thing that using --force-share in production is wrong thing to do. So,
it is needed only for debugging.. And, then, flushing bitmaps may be needed
only for debugging. So, why to flush in production?

>, regardless
> of whether the file is in use by a guest. There's also the argument that
> if qemu dies suddenly (most likely due to a bug or to a host being
> fenced), knowing what bitmaps were present in the image

actually, they didn't. They've never been in the image, only in RAM.. Like
non-persistent bitmaps.

  is better than
> having nothing at all (but conversely, if qemu dies suddenly, you are
> likely missing the bitmap data for the most recent changes, so even if
> disabled bitmaps are flushed and no longer marked in-use, they still
> won't be sufficient to allow an incremental backup, and a full backup
> will be necessary regardless of how much or little bitmap information
> got persisted).

exactly. But yes, flushing disabled bitmaps may theoretically make sense, as
they are at least valid. But about disabled bitmaps, I think it would be more
useful to teach Qemu load/unload them on demand, to not use extra RAM when
they are not needed (most of the time they don't).

> 
> While you're right that --force-share is not required to show up-to-date
> metadata, it also is not required to show nothing at all.  And at least
> knowing that a persistent bitmap is associated with a qcow2 file may
> make other things obvious - such as the fact that the image can't be
> resized (until we implement the functionality to support resize and
> bitmaps in the same image).

Hm, yes, if we have invalid IN_USE bitmaps in the image, we can't resize it..
But is it a good reason to store these bitmaps? If we don't store them,
image could be resized, why not (of course, if it is not corrupted, as
image was not closed properly)..


It all depends on the meaning of the 'persistent' bitmap. For me,
persistent means 'bitmap will be saved to the image on close'.
And they are implemented in this way. And documented in this way too:
# @persistent: the bitmap is persistent, i.e. it will be saved to the
#              corresponding block device image file on its close.

But you see them as "bitmaps which exist in the image".

I don't see real reason to flush them while Qemu running. --force-share is a back-door,
it should not be used, and I doubt that implementing something
especially for --force-share is a good idea.
Then, the only difference, is that we'll see IN_USE bitmaps in the
image if qemu stopped unexpectedly. And the only meaningful thing to
do with these invalid bitmaps is removing them.

John Snow Jan. 30, 2019, 10:51 p.m. UTC | #5

On 1/29/19 11:01 PM, Eric Blake wrote:
> On 1/28/19 12:40 PM, Andrey Shinkevich wrote:
>> Here is the update for the bitmap extension of the qcow2 specific
>> information as the output of the 'qemu-img info' command.
>> The version #7 was in email with the message ID:
>> <[e-mail]>
>>
>> v8:
>> The output benchmark files for the qemu-iotests, namely 060, 065 082, 198
>> and 206, were modified to show the bitmap extension for the qemu specific
>> information. A new test file 239 was added to the test set that checks the
>> output for the fields of the bitmap section.
>> The backward compatibility of the output for images of the version 2
>> of qcow2 was added.
> 
> So, I'm trying to test this, and I've discovered something rather
> annoying about persistent snapshots: they DON'T get written to disk
> until the qemu process exits.  In other words, even after creating a

Technically, they get written out on qcow2_inactivate -- so there is the
opportunity to write them out at key sync points if you want.

However, like Vladimir says, this data is going to be necessarily wrong
while the image is in-use, so there may not be great value in it. There
may be a lot of anti-value if users learn to use or rely on that data.

I suppose the debugging case you want to assist here is one of trust for
users -- if a user wants to take a quick poke at the image and see if
the persistent bitmap tracking really got enabled before trusting it for
the next week of operations.

> persistent bitmap via QMP (I'm trying to debug my libvirt API for
> incremental snapshots, so I did this via 'virsh snapshot-create-as $dom
> name', but it boils down to a QMP transaction with
> 'block-dirty-bitmap-add' as one of the commands), running:
> 
> $ qemu-img info -U Active1.qcow2
> 
> shows
>     bitmaps:
>     refcount bits: 16
> 
> for as long as the qemu process is running. What does it take to force a
> qcow2 image to write out its current set of known bitmaps to disk, even
> if they are known to be potentially dirty? Should it happen any time we
> flush L1/L2/refcount tables?  On a periodic but slow timer (say once
> every 5 minutes)? Other ideas?  I know we don't want to be flushing the
> full bitmap contents on every change to the in-memory internal bitmap,
> but meta-changes (such as adding a bitmap) seem like the sort of thing
> where it's worth flushing the qcow2 file; particularly when adding the
> bitmap via QMP 'transaction' which goes to the bother of flushing all
> pending I/O in order to properly roll back on failure (which means on
> success, it would be nice for the new bitmap name to show up in the
> qcow2 header, even if the contents of the bitmap are not up-to-date).
>