qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

[Mark Mielke]

On Wed, Aug 5, 2020 at 4:19 AM Andrea Bolognani <abologna at redhat.com> wrote:

> On Wed, 2020-08-05 at 02:09 -0400, Mark Mielke wrote:
> > In testing qemu-5.1rc2 on my Fedora 32 home system, I found that
> > the Fedora rawhide package has broken out both the QXL display
> > device and the USB redirect device into separate RPM modules:
> >
> > qemu-device-display-qxl.x86_64         2:5.1.0-0.1.rc2.fc32
> > qemu-device-usb-redirect.x86_64        2:5.1.0-0.1.rc2.fc32
> >
> > The upgrade from 5.0.0 to 5.1.0 does not treat these sub-packages
> > as mandatory packages, therefore a straight upgrade of packages
> > causes these domcapabilities to disappear.
> >
> > If the user tries to use libvirt after this, then existing domains
> > using QXL display device or USB redirect device will fail to start.
> > If the user then investigates and realizes that they now need to
> > install the above packages separately, they find that qemu-kvm
> > recognizes the modules right away, but libvirt does not. This looks
> > to be due to the libvirt domcapabilities cache?
> I guess we need to start checking the modules directory in addition
> to the main QEMU binary, and regenerate capabilities every time its
> contents change.
>

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
> 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.

Thanks,

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