[libvirt] [PATCH 3/3] qemu: backup: Implement support for backup disk bitmap name configuration

[Eric Blake]

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 <pkrempa at 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