When Using Vmware CPU usage stats are Zero

OS Name/Version: Debian GNU/Linux 12

Product Name/Version: 2.4.8 - 20240129.1

Problem Description:
CPU stats on all instances are stuck at 0. This server is running in VMware 7.3 with Vmwaretools installed.

Steps to reproduce:

  • Create any instance. Manage that instance. Zero CPU results.

Actions taken to resolve so far:
I have reinstalled the OS and AMP.
I have adjusted the Multicore CPU usage Calculation and ignore SMT cores without success.
I have made sure the server knows’ what kind of CPU is installed.

below is the full specs of the system Controller setup. The target Is similar setup just with much more CPU cores and RAM allocated.

Platform Debian GNU/Linux 12
System Type x86_64
CPU Model Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
CPU Layout 1S/2C/2T
Installed RAM 3880
Virtualization VMware
Module ADSModule
Module Application Application Deployment
Loaded Plugins FileManagerPlugin, EmailSenderPlugin, WebRequestPlugin, LocalFileBackupPlugin, CommonCorePlugin
Application Name AMP
Application Version
Codename Decadeus
Tools Version 2.4.8
Release Stream Mainline
Build Spec Release
Build Date 29/01/2024 18:40
InstanceID 419a4b9a-51c9-4fe3-8063-4e607024570a
Last Executable
Last Arguments
Last Process ID 56087

Is this on ESXi? What’s the output of lscpu in the VM?

That is correct, it’s on ESXI HPE-Custom-AddOn_703. (Hewlett Packard Enterprise) and this is the LSCPU output. This is on the target machine,

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 45 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 52
On-line CPU(s) list: 0-51
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
CPU family: 6
Model: 79
Thread(s) per core: 1
Core(s) per socket: 26
Socket(s): 2
Stepping: 1
BogoMIPS: 4794.44
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall
nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid
sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ib
pb stibp tpr_shadow vnmi ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid rdseed adx smap xsaveopt arat md_clear flush_l1d arch_capa
Virtualization: VT-x
Hypervisor vendor: VMware
Virtualization type: full
L1d cache: 1.6 MiB (52 instances)
L1i cache: 1.6 MiB (52 instances)
L2 cache: 13 MiB (52 instances)
L3 cache: 70 MiB (2 instances)
NUMA node(s): 1
NUMA node0 CPU(s): 0-51
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled
Vulnerability L1tf: Mitigation; PTE Inversion; VMX flush not necessary, SMT disabled
Vulnerability Mds: Mitigation; Clear CPU buffers; SMT Host state unknown
Vulnerability Meltdown: Mitigation; PTI
Vulnerability Mmio stale data: Mitigation; Clear CPU buffers; SMT Host state unknown
Vulnerability Retbleed: Mitigation; IBRS
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; IBRS, IBPB conditional, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected

Was that ‘lscpu’ from inside the VM or the bare metal host?

This was from the Debian VM.

NOTE: I also had a window VM that works properly under the same host.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.