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