If we are using -blockdev, then node names are always available
(because we set them). But when not using it, we were scraping node
names after reconnecting a new libvirtd to an existing guest (see
qemuProcessReconnect), and after any block job that may have changed
the set of node names we care about, but forgot to scrape the names
when first starting a guest. Do so now in order to allow the
checkpoint code to always have access to a node name without having to
repeat a node name scrape itself.
Signed-off-by: Eric Blake <eblake@xxxxxxxxxx>
---
Grepping for use of qemuBlockNodeNamesDetect, I see that
qemuDomainSetBlockThreshold is still scraping names, and that hotplug
and cdrom disk changes do not appear to scrape names. Either of these
situations could interfere with checkpoints; perhaps they should also
be addressed here...
---
src/qemu/qemu_process.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 75205bc121..53b8ff36f6 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -7060,6 +7060,8 @@ qemuProcessRefreshState(virQEMUDriverPtr driver,
virDomainObjPtr vm,
qemuDomainAsyncJob asyncJob)
{
+ qemuDomainObjPrivatePtr priv = vm->privateData;
+
VIR_DEBUG("Fetching list of active devices");
if (qemuDomainUpdateDeviceList(driver, vm, asyncJob) < 0)
return -1;
@@ -7075,6 +7077,9 @@ qemuProcessRefreshState(virQEMUDriverPtr driver,
VIR_DEBUG("Updating disk data");
if (qemuProcessRefreshDisks(driver, vm, asyncJob) < 0)
return -1;
+ if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_BLOCKDEV) &&
+ qemuBlockNodeNamesDetect(driver, vm, asyncJob) < 0)
+ return -1;
return 0;
}
--
2.20.1
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
