[PATCH v2 19/19] qemu: blockjob: Re-enable bitmaps after failed block-copy

[Eric Blake]

On 3/11/20 7:56 AM, Peter Krempa wrote:
> If a block-copy fails we should at least re-enable the bitmaps so that
> the operation can be re-tried.

The subject and commit body say block-copy,

> 
> Signed-off-by: Peter Krempa <pkrempa at redhat.com>
> ---
>   src/qemu/qemu_blockjob.c | 42 ++++++++++++++++++++++++++++++++++++++--
>   1 file changed, 40 insertions(+), 2 deletions(-)
> 
> diff --git a/src/qemu/qemu_blockjob.c b/src/qemu/qemu_blockjob.c
> index ed7959175a..60fe1cedf6 100644
> --- a/src/qemu/qemu_blockjob.c
> +++ b/src/qemu/qemu_blockjob.c
> @@ -1346,6 +1346,40 @@ qemuBlockJobProcessEventFailedActiveCommit(virQEMUDriverPtr driver,
>   }
> 
> 
> +static void
> +qemuBlockJobProcessEventFailedCommitCommon(virDomainObjPtr vm,
> +                                           qemuBlockJobDataPtr job,
> +                                           qemuDomainAsyncJob asyncJob)
> +{

but the function name say commit.  Is that intended?

> +    qemuDomainObjPrivatePtr priv = vm->privateData;
> +    g_autoptr(virJSONValue) actions = virJSONValueNewArray();
> +    char **disabledBitmaps = job->data.commit.disabledBitmapsBase;
> +
> +    if (!disabledBitmaps || !*disabledBitmaps)
> +        return;
> +
> +    for (; *disabledBitmaps; disabledBitmaps++) {
> +        qemuMonitorTransactionBitmapEnable(actions,
> +                                           job->data.commit.base->nodeformat,
> +                                           *disabledBitmaps);
> +    }
> +
> +    if (qemuBlockReopenReadWrite(vm, job->data.commit.base, asyncJob) < 0)
> +        return;
> +
> +    if (qemuDomainObjEnterMonitorAsync(priv->driver, vm, asyncJob) < 0)
> +        return;
> +
> +    qemuMonitorTransaction(priv->mon, &actions);
> +
> +    if (qemuDomainObjExitMonitor(priv->driver, vm) < 0)
> +        return;
> +
> +    if (qemuBlockReopenReadOnly(vm, job->data.commit.base, asyncJob) < 0)
> +        return;
> +}

Does it really matter? The only reason a bitmap is left enabled in a 
backing image when we create an external snapshot is because it was 
easier to leave it alone than to temporarily reopen the backing image 
read-write just to disable the bitmap.  But as long as no writes to the 
backing file happen (until commit), whether it is left enabled or 
changed to disabled doesn't affect behavior; so we could also argue that 
if we changed it to disabled prior to attempting commit, then commit 
fails, it really doesn't matter if we leave it disabled rather than 
trying to re-enable it (just to have it be re-disabled on the retry 
attempt).

But on the grounds of trying to leave things as close to what they were 
before failure, I'm okay with this patch, if you can straighten out my 
confusion on naming.

Reviewed-by: Eric Blake <eblake at redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org