On Wed, Jun 01, 2022 at 14:50:20 +0200, Jiri Denemark wrote:
When a domain has a guest agent channel enabled and the agent is
running
in the guest, we will get VSERPORT_CHANGE event on a destination host as
soon as we start vCPUs there. This is not an issue for normal migration,
but post-copy migration will remain running after we started vCPUs on
the destination. If it runs for more than 30s, the VSERPORT_CHANGE event
handler will fail to get a job and log the following error message:
Timed out during operation: cannot acquire state change lock (held
by monitor=remoteDispatchDomainMigrateFinish3Params)
and of course we will think the guest agent is not connected and thus
all APIs talking to it will fail. Until the agent or libvirt daemon is
restarted.
Luckily we only need to update the channel state (to mark it as
connected) and connect to the agent neither of which conflicts with
migration. Thus we can safely enable processing this event during
migration.
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
Notes:
Version 2:
- new patch
src/qemu/qemu_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 01c4a8470a..637106f1b3 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -3993,7 +3993,7 @@ processSerialChangedEvent(virQEMUDriver *driver,
memset(&dev, 0, sizeof(dev));
}
- if (qemuDomainObjBeginJob(driver, vm, VIR_JOB_MODIFY) < 0)
+ if (qemuDomainObjBeginJob(driver, vm, VIR_JOB_MIGRATION_SAFE) < 0)
return;
It's worth noting that in certain cases we modify the domain state and
don't take the job ... it's especially true for .. the domain state,
which I always found peculiar.
Anyways,
with the appropriate rename based on the previous patch:
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>