Bug inc after qemu restart

[lukenowak]

I've detected in real usage that qmpbackup can't continue after finished backup and graceful qemu restart, so here it is a test replicating this situation.

Attached full test log.
test.log

[lukenowak]

Attached a test result for qmpbackup v0.50 and more recent qemu - 10.2.0.
test-qmpbackup-v0.50-qemu-10.2.0.log

[lukenowak]

The qmpbackup 0v.45 works well with provided test scenario, run log attached.

test-qmpbackup-v0.45-qemu-10.2.0.log

[abbbi]

see:

https://qemu.weilnetz.de/doc/10.1/interop/bitmaps.html#bitmap-persistence

[..]
Bitmap Persistence
As outlined in Supported Image Formats, QEMU can persist bitmaps to qcow2 files. Demonstrated in Creation: block-dirty-bitmap-add, passing persistent: true to block-dirty-bitmap-add will persist that bitmap to disk.

Persistent bitmaps will be automatically loaded into memory upon load, and will be written back to disk upon close. Their usage should be mostly transparent.

However, if QEMU does not get a chance to close the file cleanly, the bitmap will be marked as +inconsistent at next load and considered unsafe to use for any operation. At this point, the only valid operation on such bitmaps is block-dirty-bitmap-remove.
[..]

is the qemu process actually killed in a way it is able to persist the bitmaps or not?

[abbbi]

this showcase actually seems to demonstrate what happens if qemu doesnt get the chance to persist the bitmaps in the qcow file. I think its fine for the incremental backup to fail, because if silently ignoring this situation it may lead to data-loss.

[abbbi]

the main question is: does qemu-img show the bitmap or not? If not, the qemu process had no chance to write the bitmap to the qcow image before it was killed.