On Thu, May 12, 2022 at 13:30:57 +0200, Jiri Denemark wrote: > On Thu, May 12, 2022 at 12:41:57 +0200, Peter Krempa wrote: > > 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@xxxxxxxxxx> > > > > --- > > > > > > > > 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? > > I guess the migration would just hang waiting for an event that never > comes. But I guess it should be fairly easy to check whether events are > enabled before starting a migration and report an error instead of > hanging. Leaving the VM in a hanging migration would be bad, but if we can just refuse it I'd be okay with that.
