qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

Jim Fehlig jfehlig at suse.com
Thu Aug 20 14:56:28 UTC 2020


On 8/20/20 6:54 AM, Christian Ehrhardt wrote:
> 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.

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

The daemon could then check changes to this file when validating the cache. I'm 
not familiar enough with deb packaging to know if there is a similar mechanism 
to filetrigger.

Regards,
Jim





More information about the libvir-list mailing list