When reconnecting we populate only the capability flags from the XML as
we need to know the exact flags that were present when starting the VM.
On the other hand the machine type data is not stored as it wasn't
really used after startup. While storing all of the data into the status
XML would be theoretically possible, with machine-type specific data it
makes no sense to do so, and thus the data can be re-probed from the
current instance.
Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
---
src/qemu/qemu_process.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index a6ed69cfe2..3e1198a564 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -8816,6 +8816,38 @@ qemuProcessRefreshCPU(virQEMUDriver *driver,
}
+/**
+ * qemuProcessReloadMachineTypes:
+ *
+ * Reload machine type information into the 'qemuCaps' object from the current
+ * qemu.
+ */
+static int
+qemuProcessReloadMachineTypes(virDomainObj *vm)
+{
+ qemuDomainObjPrivate *priv = vm->privateData;
+ bool fail = false;
+
+ qemuDomainObjEnterMonitor(vm);
+
+ if (virQEMUCapsInitQMPArch(priv->qemuCaps, priv->mon) < 0)
+ fail = true;
+
+ if (!fail &&
+ virQEMUCapsProbeQMPMachineTypes(priv->qemuCaps,
+ vm->def->virtType,
+ priv->mon) < 0)
+ fail = true;
+
+ qemuDomainObjExitMonitor(vm);
+
+ if (fail)
+ return -1;
+
+ return 0;
+}
+
+
struct qemuProcessReconnectData {
virQEMUDriver *driver;
virDomainObj *obj;
@@ -8950,6 +8982,11 @@ qemuProcessReconnect(void *opaque)
goto error;
}
+ /* Reload and populate machine type data into 'qemuCaps' as that is not
+ * serialized into the status XML. */
+ if (qemuProcessReloadMachineTypes(obj) < 0)
+ goto error;
+
if (qemuDomainAssignAddresses(obj->def, priv->qemuCaps,
driver, obj, false) < 0) {
goto error;
--
2.41.0
