Red Hat Bugzilla – Bug 866999
CPU topology is missing in capabilities XML when libvirt fails to detect host CPU model
Last modified: 2013-02-21 02:10:12 EST
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:
_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.
Patch sent upstream for review: https://www.redhat.com/archives/libvir-list/2012-October/msg00976.html
Fixed upstream by v0.10.2-199-gf1c7010: commit f1c70100409562c3f402392aa667732e5f89a2c4 Author: Jiri Denemark <jdenemar@redhat.com> 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.
In POST: http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-October/msg00992.html
Requesting rhel-6.3.z so that we can test rhev-3.1.0 on virtual hosts which tickle this bug.
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>
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