Re: [Qemu-devel] [PATCH v8 0/2] qemu-img info lists bitmap directory entries
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: >> <1544698788-52893-1-git-send-email-andrey.shinkev...@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 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). >
Re: [Qemu-devel] [PATCH v8 0/2] qemu-img info lists bitmap directory entries
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. -- Best regards, Vladimir
Re: [Qemu-devel] [PATCH v8 0/2] qemu-img info lists bitmap directory entries
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). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v8 0/2] qemu-img info lists bitmap directory entries
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: >> <1544698788-52893-1-git-send-email-andrey.shinkev...@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). > 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
Re: [Qemu-devel] [PATCH v8 0/2] qemu-img info lists bitmap directory entries
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.shinkev...@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 signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH v8 0/2] qemu-img info lists bitmap directory entries
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.shinkev...@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. 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 -- 1.8.3.1
