Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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 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 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.
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.
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.
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.
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."