[PATCH v2 18/19] qemu: blockjob: Handle bitmaps after finish of normal block-commit
Eric Blake
eblake at redhat.com
Wed Mar 11 21:48:14 UTC 2020
On 3/11/20 7:56 AM, Peter Krempa wrote:
> Merge the bitmaps into base of the block commit after the job finishes.
>
> Signed-off-by: Peter Krempa <pkrempa at redhat.com>
> ---
> src/qemu/qemu_blockjob.c | 53 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/src/qemu/qemu_blockjob.c b/src/qemu/qemu_blockjob.c
> index 63f1cc79c3..ed7959175a 100644
> --- a/src/qemu/qemu_blockjob.c
> +++ b/src/qemu/qemu_blockjob.c
> @@ -1049,6 +1049,56 @@ qemuBlockJobDeleteImages(virQEMUDriverPtr driver,
> }
> }
>
> +
> +/**
> + * qemuBlockJobProcessEventCompletedCommitBitmaps:
> + *
> + * Handles the bitmap changes after commit. This function shall return -1 on
> + * monitor failures.
s/shall return/returns/ sounds less stodgy :)
> + */
> +static int
> +qemuBlockJobProcessEventCompletedCommitBitmaps(virDomainObjPtr vm,
> + qemuBlockJobDataPtr job,
> + qemuDomainAsyncJob asyncJob)
> +{
> + qemuDomainObjPrivatePtr priv = vm->privateData;
> + g_autoptr(virHashTable) blockNamedNodeData = NULL;
> + g_autoptr(virJSONValue) actions = NULL;
> +
> + if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_BLOCKDEV_REOPEN))
> + return 0;
> +
> + if (!(blockNamedNodeData = qemuBlockGetNamedNodeData(vm, asyncJob)))
> + return -1;
> +
> + if (qemuBlockBitmapsHandleCommitFinish(job->data.commit.top,
> + job->data.commit.base,
> + blockNamedNodeData,
> + &actions,
> + job->data.commit.disabledBitmapsBase) < 0)
> + return 0;
> +
> + if (!actions)
> + return 0;
> +
> + if (qemuBlockReopenReadWrite(vm, job->data.commit.base, asyncJob) < 0)
> + return -1;
> +
> + if (qemuDomainObjEnterMonitorAsync(priv->driver, vm, asyncJob) < 0)
> + return -1;
> +
> + qemuMonitorTransaction(priv->mon, &actions);
> +
> + if (qemuDomainObjExitMonitor(priv->driver, vm) < 0)
> + return -1;
> +
> + if (qemuBlockReopenReadOnly(vm, job->data.commit.base, asyncJob) < 0)
> + return -1;
Earlier in the series, you ignored failure to restore readonly (leaving
things read-write isn't ideal, but isn't a show-stopper to correct
operation). Any reason why that use was different than this where you
treat it as fatal?
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
More information about the libvir-list
mailing list