Re: [Qemu-devel] [PATCH v8 0/2] qemu-img info lists bitmap directory entries

[Vladimir Sementsov-Ogievskiy]

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:
>> <address@hidden>
>>
>> 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?


-- 
Best regards,
Vladimir