On Thu, May 12, 2022 at 10:55:47AM +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 > 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. libvirt 1.2.17 was released in Jul 2015 QEMU 3.1.0 was released in Dec 2018 New QEMU has periodically introduced CLI changes that made it incompatible with older libvirt. Given that 3+1/2 year gap, I feels like there is a pretty decent chance that it was impossible to ever start QEMU 3.3.0 using a libvirt 1.2.17. If so, we don't have anything to worry about from an upgrade POV With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
