Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1861280

Summary:	Domain capabilities are not updated between virsh calls
Product:	Red Hat Enterprise Linux Advanced Virtualization	Reporter:	YunmingYang <yunyang>
Component:	libvirt	Assignee:	Michal Privoznik <mprivozn>
Status:	CLOSED ERRATA	QA Contact:	Jing Qi <jinqi>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.3	CC:	agedosier, berrange, clalancette, extras-qa, itamar, jdenemar, jforbes, jsuchane, kkoukiou, laine, leiwang, libvirt-maint, lmen, mmarusak, mpitt, mprivozn, veillard, virt-maint, virt-maint, wshi, xchen, xuzhang, yalzhang, ymao, yunyang
Target Milestone:	rc	Keywords:	Upstream
Target Release:	8.4	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	libvirt-6.10.0-1.el8	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1807198	Environment:
Last Closed:	2021-05-25 06:42:26 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:	6.10.0
Embargoed:
Bug Depends On:	1807198
Bug Blocks:

Description YunmingYang 2020-07-28 08:21:22 UTC

+++ This bug was initially created as a clone of Bug #1807198 +++

On the new Fedora 32 domain capabilities do not get updated dynamically as it is happening on Fedora 31. Workaround I found is to restart libvirtd service.

Version-Release number of selected component (if applicable):
libvirt-client-6.0.0-1.fc32.x86_64

How reproducible:
1. Notice that value points to to `/usr/share/edk2/ovmf/OVMF_CODE.fd`
```
# virsh domcapabilities
<domainCapabilities>
...snip...
  <os supported='yes'>
    <enum name='firmware'>
      <value>efi</value>
    </enum>
    <loader supported='yes'>
      <value>/usr/share/edk2/ovmf/OVMF_CODE.fd</value>
      <enum name='type'>
...snip...
```
2. `rm -rf /usr/share/edk2/*`
3. Observe that it still points to the path, even though it does not exist.
```
# virsh domcapabilities
<domainCapabilities>
...snip...
  <os supported='yes'>
    <enum name='firmware'>
      <value>efi</value>
    </enum>
    <loader supported='yes'>
      <value>/usr/share/edk2/ovmf/OVMF_CODE.fd</value>
      <enum name='type'>
...snip...
```
4. `systemctl restart libvirtd`
5.  After restarting the service the value is now updated.
```
#  virsh domcapabilities
<domainCapabilities>
...snip...
    <enum name='firmware'>
      <value>efi</value>
    </enum>
    <loader supported='yes'>
      <enum name='type'>
        <value>rom</value>
        <value>pflash</value>
...snip...
```

Expected results:
I would expect that the values would be updated even without restarting of the service. It works like that on Fedora 31.

Comment 1 YunmingYang 2020-07-28 08:23:07 UTC

*** Bug 1859005 has been marked as a duplicate of this bug. ***

Comment 3 Michal Privoznik 2020-11-17 11:30:37 UTC

Some patches were pushed upstream:

19c4c6f8fd qemu: Remove virQEMUDomainCapsCache code
7db61843b0 qemu: Don't cache domCaps in virQEMUDriverGetDomainCapabilities()
4b487e1052 conf: Drop virDomainCapsDeviceDefValidate()
a33279daa8 qemu: Validate video model
5216304bfe qemu: Validate RNG model

v6.9.0-287-g19c4c6f8fd

but there are also follow up patches:

https://www.redhat.com/archives/libvir-list/2020-November/msg00905.html

Comment 4 Michal Privoznik 2020-11-18 09:06:54 UTC

And I just merged the follow up patches:

318658b36b qemu_validate: Deduplicate code for graphics type check
919ff9debf domcaps: Report egl-headless graphics type
5ea08a33bf qemu_validate: Deduplicate code for RNG model check
d009f5b400 qemu_validate: Deduplicate code for video model check
4f8677cee2 domain_capabilities: Introduce VIR_DOMAIN_CAPS_ENUM_IS_SET

v6.9.0-304-g318658b36b

Comment 5 Jing Qi 2020-12-08 09:04:01 UTC

Verified with libvirt-daemon-6.10.0-1.module+el8.4.0+8898+a84e86e1.x86_64 

S1: Remove the existing dir of OVMF_CODE.secboot.fd and comparing the change of output from virsh domcapabilities

1. Get the output of "virsh domcapabilities"

# virsh domcapabilities

<domainCapabilities>
  <path>/usr/libexec/qemu-kvm</path>
  <domain>kvm</domain>
  <machine>pc-i440fx-rhel7.6.0</machine>
  <arch>x86_64</arch>
  <vcpu max='240'/>
  <iothreads supported='yes'/>
  <os supported='yes'>
    <enum name='firmware'/>
    <loader supported='yes'>
      <value>/usr/share/OVMF/OVMF_CODE.secboot.fd</value>
      <enum name='type'>
        <value>rom</value>
        <value>pflash</value>
      </enum>
      <enum name='readonly'>
        <value>yes</value>
        <value>no</value>
      </enum>
 
2. Remove the dir in the value of loader.
  # mv /usr/share/OVMF /usr/share/OVMF.backup

3. Get the output from "virsh domcapabilities"

  # virsh domcapabilities
 <os supported='yes'>
    <enum name='firmware'/>
    <loader supported='yes'>
      <enum name='type'>
        <value>rom</value>
        <value>pflash</value>
      </enum>
      <enum name='readonly'>
        <value>yes</value>
        <value>no</value>
      </enum>
      <enum name='secure'>
        <value>no</value>
      </enum>
    </loader>

4. Restore /usr/share/OVMF.
  # mv /usr/share/OVMF.backup /usr/share/OVMF

5. Check the output from "virsh domcapabilities"
  Step: #virsh domcapabilities

   <domainCapabilities>
  <path>/usr/libexec/qemu-kvm</path>
  <domain>kvm</domain>
  <machine>pc-i440fx-rhel7.6.0</machine>
  <arch>x86_64</arch>
  <vcpu max='240'/>
  <iothreads supported='yes'/>
  <os supported='yes'>
    <enum name='firmware'/>
    <loader supported='yes'>
      <value>/usr/share/OVMF/OVMF_CODE.secboot.fd</value>
      <enum name='type'>
        <value>rom</value>
        <value>pflash</value>
      </enum>
      <enum name='readonly'>
        <value>yes</value>
        <value>no</value>
      </enum>
 
  Result: the value of "/usr/share/OVMF/OVMF_CODE.secboot.fd" in loader is restored.

Comment 10 errata-xmlrpc 2021-05-25 06:42:26 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (virt:av bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:2098