RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1850654 - hypervisor-cpu-compare doesn't accept capabilities cpu definition
Summary: hypervisor-cpu-compare doesn't accept capabilities cpu definition
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libvirt
Version: 8.3
Hardware: s390x
OS: Linux
medium
high
Target Milestone: rc
: 8.4
Assignee: Tim Wiederhake
QA Contact: smitterl
URL:
Whiteboard:
Depends On: 1660904
Blocks: 1776265
TreeView+ depends on / blocked
 
Reported: 2020-06-24 15:59 UTC by smitterl
Modified: 2020-11-05 13:00 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-19 15:53:47 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github autotest tp-libvirt pull 3141 0 None closed Filter out hypervisor-cpu-compare on s390x 2021-01-27 06:17:06 UTC
IBM Linux Technology Center 186435 0 None None None 2020-06-25 09:46:19 UTC
Red Hat Bugzilla 1660904 1 None None None 2023-06-12 10:37:24 UTC

Description smitterl 2020-06-24 15:59:26 UTC 
Description of problem:
CPU xml definition as given by virsh capabilities is not accepted.

Version-Release number of selected component (if applicable):
libvirt-client-6.0.0-24.module+el8.3.0+7105+0cc49779.s390x


How reproducible:
100%

Steps to Reproduce:
1. virsh capabilities > caps.xml
>>
...
    <cpu>
      <arch>s390x</arch>
      <topology sockets='1' dies='1' cores='8' threads='1'/>
      <pages unit='KiB' size='4'/>
      <pages unit='KiB' size='1024'/>
    </cpu>
...
2. Put <cpu>...</cpu> from step 1 into cpu.xml
3. virsh hypervisor-cpu-baseline cpu.xml

Actual results:
error: Failed to compare hypervisor CPU with cpu.xml
error: XML error: Missing CPU model name

Expected results:
Not sure. On x86_64 result is, this depends on the environment IIUC, I got:
CPU described in /root/cpu-caps.xml is incompatible with the CPU provided by hypervisor on the host.

Additional info:
virsh man entry for hypervisor-cpu-compare: "The host CPU definition is the <cpu> element and its contents as printed by the capabilities command."
Comment 1 IBM Bug Proxy 2020-06-25 16:12:07 UTC 
------- Comment From Collin.Walling 2020-06-25 12:05 EDT-------
s390 is a bit of a special case here.

Other archs (at least x86) will report a definition for the host CPU via virsh capabilities. S390 does not do this -- it reports a "close enough" host CPU model, which can informally be referred to as the "hypervisor CPU model", via the virsh domcapabilities command.

This "hypervisor CPU model" reports features that are exposed to the hypervisor, which may not necessarily be 1:1 with what the host capabilities are.

The results look correct to me, but perhaps we should document that s390 should use domcapabilities over capabilities?
Comment 2 IBM Bug Proxy 2020-09-02 08:41:05 UTC 
------- Comment From tstaudt.com 2020-09-02 04:34 EDT-------
Hello Red Hat,

what do you think about documenting this?
Potential candidates are e.g. the virsh man page, the libvirt domain web page or one the Virtualization Guides / Red Books.
Comment 5 Thomas Huth 2020-09-23 07:21:57 UTC 
After reading through the original bug description a second time, I noticed that smitterl referenced the man page of virsh hypervisor-cpu-compare ... so if you read that man page, it indeed sounds like the output of "virsh capabilities" should be a valid input for the other commands... Thus I think the information should rather be added to the man page of virsh, and not to the Virtualization Guides or the webpage.
Comment 7 Jiri Denemark 2020-09-23 16:51:34 UTC 
The <cpu> element in host capabilities does not contain any <model> element
because libvirt itself cannot detect the host CPU. It can do so by asking QEMU
and the result is shown in domain capabilities XML. I think the existing
behavior is correct. Libvirt should refuse to make a baseline computation when
the CPU model is not specified.

The documentation of virConnectBaselineHypervisorCPU says:

    For best results the host-model CPUs as advertised by
    virConnectGetDomainCapabilities() should be passed in @xmlCPUs.

which I believe should be enough. Perhaps we should mention something like
that in virsh man page.
Comment 9 Tim Wiederhake 2020-10-09 13:02:54 UTC 
Proposed patch: https://www.redhat.com/archives/libvir-list/2020-October/msg00696.html
Comment 10 Michal Privoznik 2020-10-15 09:40:24 UTC 
Merged upstream as:

4bd0633211 docs: Expand on recommendation in hypervisor-cpu-baseline description

v6.8.0-327-g4bd0633211
Comment 12 smitterl 2020-10-19 15:53:47 UTC 
Given that the observed behavior is correct and the patch has already been merged upstream, I'm closing this as UPSTREAM. Please, shout if you disagree.
Note You need to log in before you can comment on or make changes to this bug.