Bug 1836351 - libvirt: Fix virConnectGetDomainCapabilities() call with empty cache
Summary: libvirt: Fix virConnectGetDomainCapabilities() call with empty cache
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: libvirt
Version: 8.2
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: 8.2
Assignee: Andrea Bolognani
QA Contact: Luyao Huang
URL:
Whiteboard:
Depends On:
Blocks: 1842869 1843534
TreeView+ depends on / blocked
 
Reported: 2020-05-15 16:46 UTC by Andrea Bolognani
Modified: 2020-07-28 07:14 UTC (History)
10 users (show)

Fixed In Version: libvirt-6.0.0-21.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1843534 (view as bug list)
Environment:
Last Closed: 2020-07-28 07:13:31 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:3172 0 None None None 2020-07-28 07:14:27 UTC

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


Note You need to log in before you can comment on or make changes to this bug.