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@xxxxxxxxxx>
---
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
