qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

[Christian Ehrhardt]

On Thu, Aug 20, 2020 at 12:43 PM Martin Wilck <mwilck at 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