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.
