[RFC PATCH 28/41] qemuDomainStorageSourcePrivate: Add per-source private blockjob

[Eric Blake]

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