qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?

[Peter Krempa]

On Wed, Aug 05, 2020 at 02:09:46 -0400, Mark Mielke wrote:
> 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?

Does the original qemu package still install everything? If a package is
split, the original package still should install everything for
compatibility.

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

Well, libvirt certainly needs to include the list of modules and their
ctimes in the cache now and trigger a re-query if this changes.

The cache itself is meant as an optimization so users shouldn't need to
do anything or limit what's being done.