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 <pkrempa@xxxxxxxxxx>
> > ---
> > 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.
