qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

[Mark Mielke]

Hi all:

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
 @@commandline
qemu-device-usb-redirect.x86_64        2:5.1.0-0.1.rc2.fc32
 @@commandline

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?

The domcapabilities cache will be automatically updated only under certain
conditions such as the qemu binary ctime changing - but that isn't
triggering any action here? With the devices broken out into modules, such
as the Fedora rawhide RPM .spec file is proposing, this allows the devices
to be individually installed or uninstalled at any time, and causes libvirt
domcapabilities cache to be out-of-date.

I was able to sometimes see it work by downgrading to qemu-5.0, upgrading
to qemu-5.1rc2, and installing the device packages prior to calling "virsh
domcapabilities" (or otherwise using them). I was also able to do the same
by removing the libvirt cache files and restarted libvirtd service. Both of
these are pretty non-obvious actions for a user.

I'm wondering how to codify this when I use it for real on a production
system. The upgrade path here seems unreliable, especially given that
libvirt domcapabilities cache may even persist across reboots? This means I
need to be very careful about the procedure to upgrade, and also I need to
make sure to never install or remove any of the device packages without
checking the procedure. Ouch. :-(

Thoughts?

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