[RFC PATCH 28/41] qemuDomainStorageSourcePrivate: Add per-source private blockjob
Eric Blake
eblake at redhat.com
Fri Jun 19 20:08:14 UTC 2020
On 6/9/20 10:00 AM, Peter Krempa wrote:
> We'll need to track multiple blockjobs for populating bitmaps per
> storage source for internal use. Add a variable into the storage source
> private data for this purpose.
Hmm. If the domain has two disks as well as two active bitmaps per disk,
does that really mean we are tracking four independent blockjobs when
merging in allocation data into all four bitmaps?
>
> Signed-off-by: Peter Krempa <pkrempa at redhat.com>
> ---
> src/qemu/qemu_domain.c | 1 +
> src/qemu/qemu_domain.h | 4 ++++
> 2 files changed, 5 insertions(+)
>
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 3239ac1a52..0cd9cf8582 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -1230,6 +1230,7 @@ qemuDomainStorageSourcePrivateDispose(void *obj)
> g_clear_pointer(&priv->secinfo, qemuDomainSecretInfoFree);
> g_clear_pointer(&priv->encinfo, qemuDomainSecretInfoFree);
> g_clear_pointer(&priv->httpcookie, qemuDomainSecretInfoFree);
> + virObjectUnref(priv->blockjob);
> }
Or are you planning on only using one blockjob per disk, and then when
it is complete, merging that bitmap into multiple other bitmaps?
Should the blockjob-populate command allow multiple destination bitmaps
grouped into one job? Or is that just trading reduced libvirt
complexity for too much QMP complexity?
--
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