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