qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

[Mark Mielke]

On Wed, Aug 5, 2020 at 4:31 AM Mark Mielke <mark.mielke at gmail.com> wrote:

> On Wed, Aug 5, 2020 at 4:19 AM Andrea Bolognani <abologna at redhat.com>
> wrote:
>
>> 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.
>>
>
> I had the same thought. However, I'm expecting this will be part of Fedora
> 33 (not yet out), and the QXL display driver is possibly becoming optional?
> Within the same release of Fedora, I expect the default module list should
> be stable, but between releases it might not be? But, what about long-lived
> major releases like RHEL / CentOS? Or people who "upgrade" from the distro
> release to the "advanced virtualization" release (RHEL / CentOS 8)? I also
> would expect functionality which seems pretty default - to stay default,
> although perhaps it could be a weak package dependency or similar, to
> permit people to uninstall it?
>
> They also moved qemu-device-usb-smartcart to optional along with the
> already mentioned qemu-device-display-qxl and qemu-device-usb-redirect, and
> I believe this has happened in the past with some of the block device
> drivers, only I might not use them, so they might not have affected me? I
> think everything in the module directory is really in scope.
>

The Fedora package owner agreed, and will be correcting it so that the
default will include these packages. This addresses the upgrade case, and
the surprise factor for users merely upgrading from Fedora 32 to Fedora 33
resulting in libvirt breaking for them.

However, it does not address the exposed problem - which is that I can add
or remove individual Qemu module packages at any time, and libvirt will not
be aware of this change until some other event occurs which might not ever
occur in this workflow (even reboot!).

So, I think it is important to include the Qemu module directory in the
list of timestamps to check to determine if the domcapabilities cache
should be invalidated or not. If a module gets added or removed, the
directory timestamp should change.

I think the idea of libvirt probing the system and guessing when to
invalidate the cache based upon only a few select data points, including
ones like "qemu binary timestamp" are embedded with assumptions, is going
to continue to be a problem. But, adding the above check would close an
additional set of scenarios as covered.


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