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 :|