Description of problem: libvirt clears the capabilities cache (/var/cache/libvirt/qemu/capabilities/) when libvirtd runs a new kernel and in several other situations. However, it doesn't do so when qemu is being upgraded. Version-Release number of selected component (if applicable): libvirt 3.0.0 How reproducible: Steps to Reproduce: 1. install an old version of libvirt (I had 1.2 -- Debian Jessie's default) and qemu (I had 2.1) 2. run libvirtd and ensure that /var/cache/libvirt/qemu/capabilities is initialized 2. upgrade libvirt to 3.0.0 3. restart libvirtd and observe that /var/cache/libvirt/qemu/capabilities has been regenerated 4. upgrade qemu to 2.8 (Jessie Backports version) 5. restart libvirtd Actual results: observe that the cache files have not been regenerated Expected results: the cache files should have been regenerated, as especially in the case I'm talking about (qemu 2.1 upgraded to 2.8) a significant number of interesting new capabilities. Additional info: The specific capability that I needed was the "secrets" capability, which isn't available in Qemu 2.1+libvirt 3.0.0, but *is* available in Qemu 2.8+libvirt 3.0.0.
Well, libvirt is designed to refresh capabilities cache whenever the last status change timestamp (ctime) of the QEMU binary changes. And there's no need to restart libvirtd for that, it's enough to just make libvirt look at QEMU capabilities, e.g., by running virsh capabilities. If the cache is not refreshed, we indeed have a bug somewhere. How are you checking that capabilities were refreshed? Do you look at the presence of the specific capability you're looking for or do you compare timestamps or even contents of the files in /var/cache/libvirt/qemu/capabilities? There's no capability called "secrets". Did you mean "secret" instead? Anyway, libvirt 3.0.0 is almost two years old so unless you can reproduce this bug on current upstream version, I'm afraid you'd need to file the bug report in Debian's bug tracking system. I tried to look at commits since 3.0.0 mentioning capabilities, but I didn't notice any obvious one. Which however does not mean there was no such bug in 3.0.0.
Thanks for your patience for me to come back to respond to your request for information. Yes, I mean the 'secret' capability. However, that's completely beside the point. My point is that *on upgrade*, the cache file should be *regenerated* (however, it wasn't - as stated in the "expected results"). Kind regards,
As I said, upgrading QEMU does not trigger capabilities refresh by itself. You need to do some action which will cause libvirt to use the upgraded QEMU (e.g., start a new domain, ask for host or domain capabilities). I'm closing this bug, please reopen it in case you can reproduce the issue with current upstream libvirt. If you can only hit this bug with Debian's release of libvirt, you'd need to file a bug in their bug tracker.