Bug 1650950

Summary:	libvirt doesn't clear qemu capabilities cache upon qemu upgrade
Product:	[Community] Virtualization Tools	Reporter:	Erik Huelsmann <ehuels>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	ehuels, jdenemar, libvirt-maint, tburke
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-03-18 11:21:34 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Erik Huelsmann 2018-11-17 22:23:06 UTC

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.

Comment 1 Jiri Denemark 2018-11-19 08:51:39 UTC

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.

Comment 2 Erik Huelsmann 2020-03-13 11:15:24 UTC

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,

Comment 3 Jiri Denemark 2020-03-18 11:21:34 UTC

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.