Output of lscpu on a CentOS OpenVZ Container

So on the node level the lscpu output is fine, but if you try the same command in a CentOS* container, an error is thrown. Then there's a weird thing going on with a couple of the dual L5520s which, using Ubuntu templates, gives an lscpu output displays an incorrect core/thread total (would expect 16 in those cases). Also, Ubuntu seems to respond correctly under single proc environments (E3s) as far as I can tell.  Has this always been the way of things for CentOS containers? I've seen this popping in and out of cPanel error logs.  I'm almost certain this is easily reproduced... anybody out there?

 

CentOS 6.5 x86_64 (container)


[root@hampton logs]# lscpu

lscpu: failed to determine number of CPUs: /sys/devices/system/cpu/possible: No such file or directory

 

Scientific Linux 6.5 (container)


[root@labassu ~]# lscpu

Architecture:          x86_64

CPU op-mode(s):        32-bit, 64-bit

Byte Order:            Little Endian

CPU(s):                24

Vendor ID:             GenuineIntel

CPU family:            6

Model:                 44

Stepping:              2

CPU MHz:               2668.000

BogoMIPS:              5333.70

Virtualization:        VT-x

 

Ubu 12.04 (container)

root@jax-ctq02:~# lscpu

Architecture:          x86_64

CPU op-mode(s):        32-bit, 64-bit

Byte Order:            Little Endian

CPU(s):                24

Vendor ID:             GenuineIntel

CPU family:            6

Model:                 26

Stepping:              5

CPU MHz:               2266.698

BogoMIPS:              4533.39

Virtualization:        VT-x

 

 



A few (correct) node examples:

 

[root@********** ~]# lscpu

Architecture:          x86_64

CPU op-mode(s):        32-bit, 64-bit

Byte Order:            Little Endian

CPU(s):                24

On-line CPU(s) list:   0-23

Thread(s) per core:    2

Core(s) per socket:    6

Socket(s):             2

NUMA node(s):          2

Vendor ID:             GenuineIntel

CPU family:            6

Model:                 44

Stepping:              2

CPU MHz:               2668.000

BogoMIPS:              5333.19

Virtualization:        VT-x

L1d cache:             32K

L1i cache:             32K

L2 cache:              256K

L3 cache:              12288K

NUMA node0 CPU(s):     0-5,12-17

NUMA node1 CPU(s):     6-11,18-23

 

[root@************* ~]# lscpu

Architecture:          x86_64

CPU op-mode(s):        32-bit, 64-bit

Byte Order:            Little Endian

CPU(s):                24

On-line CPU(s) list:   0-23

Thread(s) per core:    2

Core(s) per socket:    6

Socket(s):             2

NUMA node(s):          2

Vendor ID:             GenuineIntel

CPU family:            6

Model:                 44

Stepping:              2

CPU MHz:               2668.000

BogoMIPS:              5333.19

Virtualization:        VT-x

L1d cache:             32K

L1i cache:             32K

L2 cache:              256K

L3 cache:              12288K

NUMA node0 CPU(s):     0-5,12-17

NUMA node1 CPU(s):     6-11,18-23

 

[root@************** ~]# lscpu

Architecture:          x86_64

CPU op-mode(s):        32-bit, 64-bit

Byte Order:            Little Endian

CPU(s):                16

On-line CPU(s) list:   0-15

Thread(s) per core:    2

Core(s) per socket:    4

Socket(s):             2

NUMA node(s):          2

Vendor ID:             GenuineIntel

CPU family:            6

Model:                 26

Stepping:              5

CPU MHz:               2266.698

BogoMIPS:              4532.67

Virtualization:        VT-x

L1d cache:             32K

L1i cache:             32K

L2 cache:              256K

L3 cache:              8192K

NUMA node0 CPU(s):     0-3,8-11

NUMA node1 CPU(s):     4-7,12-15

Judging that it didn't work for one template, I'm going to assume that /sys/devices/system/cpu/possible isn't virtualized by OpenVZ.  In the one case, /sys/devices/system/cpu/possible may exist only because the template was made from a running system.  Therefore the template actually contains a static file of /sys/devices/system/cpu/possible.

I could be wrong, you could verify if the template itself has that file or if the file exists after the container is stopped, but it would make sense why it doesn't show up in CentOS and it is reporting invalid information.