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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]

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:
> <1544698788-52893-1-git-send-email-andrey.shinkevich@virtuozzo.com>
> 
> 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).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]