cpu.cour_count and cpu.socket_count is wrong for VMware VMs

[mdvickst]

Opening a new issue

---

Specify type:

• Bug

Bug severity (if applicable):

• High

---

Description:

For some reason the cpu.socket_count on VMware VMs is showing very high numbers (128 sockets or 64 sockets). This impacts cpu.core_count since they are tied together. cpu.count appears to work correctly for VMs so maybe we just use that value for cpu.core_count if it is a VM (and we don't have to worry about hyperthreading)?

---

Bug Report

Version of rho:

[ 0.0.31 ]

Expected behavior:

Describe the expected behavior for the program.

Actual behavior:

Provide the actual behavior for the program.

Steps to reproduce:

List clear steps to reproduce the bug.

Environment information:

Type	Operating System	OS Version	Python Version	Virtualization
Target System	RHEL	6.8	2.4.6	VMware

[chambridge]

@mdvickst Can you provide any additional logs for this? Do we know whether the scanning user had sudo privileges (so we get the data from dmidecode) or are we falling back for these calculations?

Do you have a system this can be reproduced on?

[mdvickst]

Used root account. Attached are dmidecode and cpuinfo outputs.

dmi.txt cpuinfo.txt

[chambridge]

@mdvickst Thank you for the output. I was able to change some of the playbook handling to try and reproduce.

The large numbers appear to come from how we determine the socket count the current task runs the following pulling data from dmidecode:

- name: gather cpu.socket_count fact
  raw: /usr/sbin/dmidecode -t 4 | grep 'Socket Designation'| wc -l
  register: cpu_socket_count_cmd
  become: yes

If you look at the dmi.txt there are Socket Designation: CPU socket #0 - Socket Designation: CPU socket #63 listed which is why it comes up with 64.

if we couldn't get data from dmidecode due to escalation issues we fall back to the following /proc/cpu call:

- name: gather cpu.socket_count fact with fallback
  raw: cat /proc/cpuinfo | grep 'physical id' | sort -u | wc -l
  register: cpu_socket_count_cmd

This will gather the following from the values provided in cpuinfo.txt: 2

So the question is should we be changing what we are getting from dmidecode? Is it wrong some how, or wrong for vms?

[mdvickst]

I'm not aware of any documented bugs from RH or VMware on this. I have seen this in multiple output files from different environments. Maybe we just use cpu.count for cpu.core_count in the virt.type = "vmware"? Probably a temporary fix till we can find the root cause.

[chambridge]

@mdvickst I see. You want a new release cut with this workaround then?