qemu modularization of qemu-5.1 vs libvirt domcapabilities cache?
Peter Krempa
pkrempa at redhat.com
Wed Aug 5 08:17:27 UTC 2020
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.
More information about the libvir-list
mailing list