On Thu, May 12, 2022 at 13:32:38 +0200, Peter Krempa wrote: > 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 <jdene...@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? > > > > 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.
Actually, doing so would not make any sense. We could just as easy enable the capability on reconnect if it's not enabled. Which is the alternative solution I described above in the Notes section :-) Jirka
