qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

Mark Mielke mark.mielke at gmail.com
Thu Aug 20 15:14:56 UTC 2020


On Thu, Aug 20, 2020 at 8:55 AM Christian Ehrhardt <
christian.ehrhardt at canonical.com> wrote:

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

Earlier in this thread - I think one or two of us had asked about the
timestamp on the directory that contains the modules.

I'm wondering if a "last_packaging_change" provides any value over and
above the timestamp of the directory itself? Wouldn't the directory be best
- as it would work automatically for both distro packaging as well as
custom installs?

-- 
Mark Mielke <mark.mielke at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200820/b32def8e/attachment-0001.htm>


More information about the libvir-list mailing list