[libvirt PATCH 4/4] qemu: Enable migration events only for fresh QEMU process

[Peter Krempa]

On Thu, May 12, 2022 at 12:40:54 +0200, Peter Krempa wrote:
> On Thu, May 12, 2022 at 10:55:47 +0200, Jiri Denemark wrote:
> > Every running QEMU process we are willing to reconnect (i.e., at least
> > 3.1.0) supports migration events and we can assume the capability is
> > already enabled since last time libvirt daemon connected to its monitor.
> > 
> > Well, it's not guaranteed though. If libvirt 1.2.17 or older was used to
> > start QEMU 3.1.0 or newer, migration events would not be enabled. And if
> > the user decides to upgrade libvirt from 1.2.17 to 8.4.0 while the QEMU
> > process is still running, they would not be able to migrate the domain
> 
> But doesn't the function below actually enable the events? Or is there
> something else that needs to be done?
> 
> Such that we simply could enable the events and be done with it?
> 
> > because of disabled migration events. I think we do not really need to
> > worry about this scenario as libvirt 1.2.17 is 7 years old while QEMU
> > 3.1.0 was released only 3.5 years ago. Thus a chance someone would be
> > running such configuration should be fairly small and a combination with
> > upgrading 1.2.17 to 8.4.0 (or newer) with running domains should get it
> > pretty much to zero. The issue would disappear ff the ancient libvirt is
> > first upgraded to something older than 8.4.0 and then to the current
> > libvirt.
> > 
> > Signed-off-by: Jiri Denemark <jdenemar at redhat.com>
> > ---
> > 
> > Notes:
> >     I was hoping we could do this without any downside, but it appeared this
> >     was not possible. In case someone still thinks this would be an issue, I
> >     can take an alternative solution and check whether migration events are
> >     enabled when reconnecting to QEMU monitor.

Aaah, never mind. You want to avoid setting it all the time. Well I
think I would be okay with that, does our code handle the absence of
events properly?