Re: qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

On Wed, Aug 5, 2020 at 4:19 AM Andrea Bolognani <abologna(a)redhat.com&gt; wrote: I was wondering if checking /usr/lib64/qemu (the module directory) might be sufficient? Adding or removing content from the modules directory would potentially change the domcapabilities? I don't know if there is a reliable way of determining this directory from libvirt? In general - a user might add or remove such packages at any time, and expect it to automatically work. I don't think having a list of modules would be effective, but if just checking the module directory itself worked, that could be the right compromise? That said, if upgrading QEMU results in losing features, even though 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. Thanks, -- Mark Mielke <mark.mielke(a)gmail.com&gt;