On 8/20/20 8:56 AM, Jim Fehlig wrote:
On 8/20/20 6:54 AM, Christian Ehrhardt wrote:
On Thu, Aug 20, 2020 at 12:43 PM Martin Wilck <mwilck@xxxxxxxx> 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.
That would require changes in libvirt and the various module packages right? Are
you fine with Daniel's suggestion of handling this all within libvirt? E.g. on
the packaging side libvirt could define a trigger to be notified when the
modules dir is updated and touch a well-known file
%filetriggerin -- %{_libdir}/qemu
touch /var/cache/libvirt/qemu/capabilities/module-changed
%filetriggerun -- %{_libdir}/qemu
touch /var/cache/libvirt/qemu/capabilities/module-changed
Hmm, this is still problematic for session mode. I think your suggestion covers
both system and session modes nicely.
If we can agree on an approach I'd be happy to take a stab at implementing it.
Regards,
Jim
