On 12/12/19 11:18 AM, Peter Krempa wrote:
Re-create any active persistent bitmap in the snapshot overlay image so
that tracking for a checkpoint is persisted. While this basically
duplicates data in the allocation map it's currently the only possible
way as qemu can't mirror the allocation map into a dirty bitmap if we'd
ever want to do a backup.
Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
---
src/qemu/qemu_driver.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index d2769dab1a..8ccd6b7c97 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -15223,6 +15223,42 @@ qemuDomainSnapshotDiskCleanup(qemuDomainSnapshotDiskDataPtr data,
}
+/**
+ * qemuDomainSnapshotDiskBitmapsPropagate:
+ *
+ * This function propagates any active persistent bitmap present in the original
+ * image into the new snapshot. We leave the original bitmap active as in cases
+ * when the overlay is discarded (snapshot revert with abandoning the history)
+ * everything works as expected.
That, and the backing image is now read-only so the active bitmap in
that layer won't be getting any more writes until you merge the active
layer back in via commit.
+ * */
Funny looking comment end.
+static int
+qemuDomainSnapshotDiskBitmapsPropagate(qemuDomainSnapshotDiskDataPtr dd,
+ virJSONValuePtr actions,
+ virHashTablePtr blockNamedNodeData)
+{
+ qemuBlockNamedNodeDataPtr entry;
+ size_t i;
+
+ if (!(entry = virHashLookup(blockNamedNodeData, dd->disk->src->nodeformat)))
+ return 0;
+
+ for (i = 0; i < entry->nbitmaps; i++) {
+ qemuBlockNamedNodeDataBitmapPtr bitmap = entry->bitmaps[i];
+
+ /* we don't care about temporary, inconsistent, or disabled bitmaps */
+ if (!bitmap->persistent || !bitmap->recording || bitmap->inconsistent)
+ continue;
+
+ if (qemuMonitorTransactionBitmapAdd(actions, dd->src->nodeformat,
+ bitmap->name, true, false,
+ bitmap->granularity) < 0)
Ah, you're reproducing whatever granularity already existed (even though
so far, libvirt doesn't expose a knob for setting checkpoint bitmap
granularity, so it will always be the default unless the image was
modified behind libvirt's back).
Reviewed-by: Eric Blake <eblake@xxxxxxxxxx>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
