[libvirt PATCH v2 80/81] qemu: Fix VSERPORT_CHANGE event in post-copy migration

Peter Krempa pkrempa at redhat.com
Mon Jun 6 13:34:30 UTC 2022


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 at 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 at redhat.com>


More information about the libvir-list mailing list