Bug 1836351

Summary: libvirt: Fix virConnectGetDomainCapabilities() call with empty cache
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: Andrea Bolognani <abologna>
Component: libvirtAssignee: Andrea Bolognani <abologna>
Status: CLOSED ERRATA QA Contact: Luyao Huang <lhuang>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 8.2CC: crobinso, fdeutsch, jdenemar, jsuchane, knoel, lijin, mtessun, toneata, virt-maint, yalzhang
Target Milestone: rcKeywords: Regression, ZStream
Target Release: 8.2Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-6.0.0-21.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1843534 (view as bug list) Environment:
Last Closed: 2020-07-28 07:13:31 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:
Bug Depends On:    
Bug Blocks: 1842869, 1843534    

Description Andrea Bolognani 2020-05-15 16:46:41 UTC
The RHEL AV 8.2 build of libvirt, based on 6.0.0, is missing

  commit 6d786f95a366600e7bbae68c1b324a8131f5e2c5
  Author: Daniel P. Berrangé <berrange>
  Date:   Fri Jan 17 13:25:02 2020 +0000

    qemu: fixing auto-detecting binary in domain capabilities

    The virConnectGetDomainCapabilities API accepts either a binary path
    to the emulator, or desired guest arch. If guest arch is not given,
    then the host arch is assumed.

    In the case where the binary is not given, the code tried to find the
    emulator binary in the existing list of cached emulator capabilities.
    This is not valid since we switched to lazy population of the cache in:

      commit 3dd91af01f30c5bda6328454ef49f3afece755d6
      Author: Daniel P. Berrangé <berrange>
      Date:   Mon Dec 2 13:04:26 2019 +0000

        qemu: stop creating capabilities at driver startup

    As a result of this change, if there are no persistent guests defined
    using the requested guest architecture, virConnectGetDomainCapabilities
    will fail to find an emulator binary.

    The solution is to stop relying on the cached capabilities to find the
    binary and instead use the same logic we use to pick default a binary
    per arch when populating capabilities.

    Tested-by: Boris Fiuczynski <fiuczy.com>
    Tested-by: Richard W.M. Jones <rjones>
    Reviewed-by: Michal Privoznik <mprivozn>
    Signed-off-by: Daniel P. Berrangé <berrange>

  v6.0.0-77-g6d786f95a3

As a result, KubeVirt's CI broke as soon as they tried switching to
it:

  https://github.com/kubevirt/kubevirt/pull/3268

We should backport the fix.

Comment 9 Luyao Huang 2020-06-03 07:07:34 UTC
Reproduce this issue on libvirt-daemon-6.0.0-19.module+el8.2.1+6538+c148631f.x86_64:

1. make sure there is no guest and no cache file

# ll /var/cache/libvirt/qemu/
total 0

# virsh list --all
 Id   Name   State
--------------------

2. run domcapabilities command

# virsh domcapabilities
error: failed to get emulator capabilities
error: invalid argument: unable to find any emulator to serve 'x86_64' architecture

3. define a guest

# virsh define guest.xml
Domain vm1 defined from guest.xml

4. rerun domcapabilities command
# virsh domcapabilities
<domainCapabilities>
  <path>/usr/libexec/qemu-kvm</path>
...
</domainCapabilities>


And verify this bug with libvirt-daemon-6.0.0-22.module+el8.2.1+6815+1c792dc8.x86_64:

1. make sure there is no guest and no cache file
# ll /var/cache/libvirt/qemu/capabilities/
total 0

# virsh list --all
 Id   Name   State
--------------------


2. run domcapabilities command
# virsh domcapabilities 
<domainCapabilities>
  <path>/usr/libexec/qemu-kvm</path>
...
</domainCapabilities>

3. check cache file:
# ll /var/cache/libvirt/qemu/capabilities/
total 112
-rw-------. 1 root root 111463 Jun  3 02:52 3c76bc41d59c0c7314b1ae8e63f4f765d2cf16abaeea081b3ca1f5d8732f7bb1.xml

Comment 13 errata-xmlrpc 2020-07-28 07:13:31 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, 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-2020:3172