On Thu, Aug 20, 2020 at 12:43 PM Martin Wilck <mwilck@suse.com> wrote:
On Thu, 2020-08-20 at 11:00 +0100, Daniel P. Berrangé wrote:
On Wed, Aug 05, 2020 at 10:19:26AM +0200, Andrea Bolognani wrote:
contents change.
That said, if upgrading QEMU results in losing features, even though you can recover them through additional steps I would argue that's a bug in the packaging that should be addressed on the QEMU side.
Potentially we can consider this a distro packaging problem and fix it at the RPM level.
eg the libvirt RPM can define a trigger that runs when *any* of the qemu-device* RPMs is installed/updated. This trigger can simply touch a file on disk somewhere, and libvirtd can monitor this one file, instead of having to monitor every module.
The simplest approach is to touch the qemu binaries. We discussed this already. It has the drawback that it makes "rpm -V" complain about wrong timestamps. It might also confuse backup software. Still, it might be a viable short-term workaround if nothing else is available.
Qemu already allows to save modules in /var/run/qemu/ [1] to better handle module upgrades which is already used in Debian and Ubuntu to avoid late module load errors after upgrades. This was meant for upgrades, but if libvirt would define a known path in there like /var/run/qemu/last_packaging_change the packages could easily touch it on any install/remove/update as Daniel suggested and libvirt could check this path like it does with the date of the qemu binary already. [1]: https://github.com/qemu/qemu/commit/bd83c861c0628a64997b7bd95c3bcc2e916baf2e
Cheers, Martin
-- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd