On 6/15/20 12:09 PM, Peter Krempa wrote:
Upcoming patches are going to rewrite and semantically modify how
bitmaps are handled during blockjobs. This is possible as incremental
backup is not yet fully enabled.
As the changes are going to be incompatible with any current test data
remove all test cases for bitmap handling during checkpoint deletion,
incremental backups, block commit, block copy, and bitmap validation
operations.
The tests will be gradually added back later after the code and
test-data is refactored.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
49 files changed, 2909 deletions(-)
And this is the point where we have to commit on which interface we will
stick to once we allow incremental backups by default rather than just
by opting in. With your idea of keeping multiple bitmaps active, we may
need to tweak qemu to be more efficient at how it stores bitmap
information (for example, instead of having each guest write modify the
in-memory representation of all active bitmaps, which only get flushed
to disk when closing the guest, we could instead have qemu store guest
writes into a single in-memory bitmap, then merge that into all active
bitmaps when flushing) - but that's for qemu to worry about. In the
meantime, if your n ew proposed bitmap handling is easier to manage in
libvirt, even if it costs more work in current qemu, I think we can live
with that.
I'm reluctant to ack this patch until I've seen the rest of the series
adding support back in, but unless something major turns up in the rest
of the series, the approach of a clean slate followed by a new
implementation is reasonable enough.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org