On 1/21/20 6:55 AM, Peter Krempa wrote:
On Tue, Jan 14, 2020 at 08:50:55 -0600, Eric Blake wrote:
On 1/9/20 12:31 PM, Peter Krempa wrote:
Use the user-configured name of the bitmap when merging the appropriate
bitmaps for an incremental backup so that the user can see it as
configured. Additionally expose the default bitmap name if nothing is
configured.
Signed-off-by: Peter Krempa <pkre...@redhat.com>
---
src/qemu/qemu_backup.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_backup.c b/src/qemu/qemu_backup.c
index 2cc0e6ab07..23518a5d40 100644
--- a/src/qemu/qemu_backup.c
+++ b/src/qemu/qemu_backup.c
@@ -322,7 +322,10 @@ qemuBackupDiskPrepareDataOne(virDomainObjPtr vm,
return -1;
if (incremental) {
- dd->incrementalBitmap = g_strdup_printf("backup-%s", dd->domdisk->dst);
+ if (dd->backupdisk->exportbitmap)
+ dd->incrementalBitmap = g_strdup(dd->backupdisk->exportbitmap);
Do we need to worry about the user requesting a name that would cause
conflicts with existing bitmaps in the qcow2 file? I'm worried this can
open the door for odd failures if the user accidentally stomps on names that
libvirt thought were available for its own use.
This name will be passed to a transactioned 'block-dirty-bitmap-add' so
existing bitmaps should not be overwritten.
I'm not sure whether it's worth forbidding. Users actually might want to
pick a different bitmap name when they accidentally used the one libvirt
would pick for the temporary bitmap when left blank in which case the
code would fail without any way to fix it.
Okay, it sounds like even if the user picks a problematic name, the
transaction will fail and they will at least get a useful error message
that hopefully points them to pick a better name.
In that case, no objection from me.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
