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 866999 - CPU topology is missing in capabilities XML when libvirt fails to detect host CPU model
Summary: CPU topology is missing in capabilities XML when libvirt fails to detect host...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Jiri Denemark
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 868972 876475
TreeView+ depends on / blocked
 
Reported: 2012-10-16 13:59 UTC by Yaniv Bronhaim
Modified: 2013-02-21 07:10 UTC (History)
13 users (show)

Fixed In Version: libvirt-0.10.2-5.el6
Doc Type: Bug Fix
Doc Text:
When libvirt could not find a suitable CPU model for a host CPU, it would not provide the CPU topology in host capabilities even though the topology was detected correctly. Consequently, applications that work with the host CPU topology but not with the CPU model could not see the topology in host capabilities. With this update, the host capabilities XML description contains the host CPU topology even if the host CPU model is unknown.
Clone Of:
: 876475 (view as bug list)
Environment:
Last Closed: 2013-02-21 07:10:12 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0276 0 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2013-02-20 21:18:26 UTC

Description Yaniv Bronhaim 2012-10-16 13:59:34 UTC 
Description of problem:
Running vdsm gets exception while reading libvirt capabilities

Version-Release number of selected component (if applicable):
libvirt-0.9.10-21.el6_3.5.x86_64
vdsm-4.10.1-0.18.el6.x86_64

How reproducible:
service vdsmd start

Steps to Reproduce:
1. install and run vdsm, it reproduce during vdsm startup
2.
3.
  
Actual results:
when running virsh -r capabilities we see no parameters under topology tag:
    <topology>
      <cells num='1'>
        <cell id='0'>
          <cpus num='1'>
            <cpu id='0'/>
          </cpus>
        </cell>
      </cells>
    </topology>

vdsm throws exception and fails to start:

MainThread::ERROR::2012-10-16 15:42:44,001::vdsm::84::vds::(run) Exception raised
Traceback (most recent call last):
  File "/usr/share/vdsm/vdsm", line 82, in run
    serve_clients(log)
  File "/usr/share/vdsm/vdsm", line 50, in serve_clients
    cif = clientIF.getInstance(log)
  File "/usr/share/vdsm/clientIF.py", line 126, in getInstance
    cls._instance = clientIF(log)
  File "/usr/share/vdsm/clientIF.py", line 93, in __init__
    caps.CpuTopology().cores())
  File "/usr/share/vdsm/caps.py", line 88, in __init__
    self._topology = _getCpuTopology(capabilities)
  File "/usr/lib64/python2.6/site-packages/vdsm/utils.py", line 822, in __call__
    value = self.func(*args)
  File "/usr/share/vdsm/caps.py", line 116, in _getCpuTopology
    'sockets': int(cpu.getElementsByTagName('topology')[0].
IndexError: list index out of range


Expected results:
topology should have the attributes cells, sockets, cores and threads in libvirt capabilities xml.

Additional info:
Comment 2 Jiri Denemark 2012-10-16 17:57:35 UTC 
_getCpuTopology is a function from vdsm, which parses cpu topology from /capabilities/host/cpu/topology in libvirt's capabilities XML. The /capabilities/host/topology element shown in bug description is a NUMA topology. While vdsm can use virNodeGetInfo to get the CPU topology (rather than parsing it from capabilities), I agree that we have a bug in libvirt. When host CPU model cannot be detected for some reason, we won't provide the topology even though it's known.
Comment 3 Jiri Denemark 2012-10-18 13:02:15 UTC 
Patch sent upstream for review: https://www.redhat.com/archives/libvir-list/2012-October/msg00976.html
Comment 4 Jiri Denemark 2012-10-18 14:06:04 UTC 
Fixed upstream by v0.10.2-199-gf1c7010:

commit f1c70100409562c3f402392aa667732e5f89a2c4
Author: Jiri Denemark <jdenemar>
Date:   Tue Oct 16 21:11:29 2012 +0200

    qemu: Always format CPU topology
    
    When libvirt cannot find a suitable CPU model for host CPU (easily
    reproducible by running libvirt in a guest), it would not provide CPU
    topology in capabilities XML either. Even though CPU topology is known
    and can be queried by virNodeGetInfo. With this patch, CPU topology will
    always be provided in capabilities XML regardless on the presence of CPU
    model.
Comment 5 Jiri Denemark 2012-10-19 09:29:58 UTC 
In POST: http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-October/msg00992.html
Comment 6 Dan Kenigsberg 2012-10-21 10:31:07 UTC 
Requesting rhel-6.3.z so that we can test rhev-3.1.0 on virtual hosts which tickle this bug.
Comment 9 hongming 2012-10-25 06:17:59 UTC 
Verify it as follows, the result is expected. Move its status to VERIFIED.


Versions
libvirt-0.10.2-5.el6.x86_64

Steps
Login one RHEL6.3 guest ,run the following commands.

# virsh nodeinfo
CPU model:           x86_64
CPU(s):              4
CPU frequency:       3092 MHz
CPU socket(s):       1
Core(s) per socket:  4
Thread(s) per core:  1
NUMA cell(s):        1
Memory size:         1020340 KiB


# virsh capabilities
<capabilities>

  <host>
    <uuid>616e8f71-236c-88e9-748c-72554ad5c790</uuid>
    <cpu>
      <arch>x86_64</arch>
      <topology sockets='1' cores='4' threads='1'/>
    </cpu>
    <power_management>
      <suspend_disk/>
    </power_management>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      </uri_transports>
    </migration_features>
    <topology>
      <cells num='1'>
        <cell id='0'>
          <cpus num='4'>
            <cpu id='0'/>
            <cpu id='1'/>
            <cpu id='2'/>
            <cpu id='3'/>
          </cpus>
        </cell>
      </cells>
    </topology>
    <secmodel>
      <model>selinux</model>
      <doi>0</doi>
    </secmodel>
    <secmodel>
      <model>dac</model>
      <doi>0</doi>
    </secmodel>
  </host>

</capabilities>
Comment 15 errata-xmlrpc 2013-02-21 07:10:12 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.

http://rhn.redhat.com/errata/RHSA-2013-0276.html
Note You need to log in before you can comment on or make changes to this bug.