We are very interested in CPU Ready metric data (time when a guest VM has an unblocked thread(s) and waits for a CPU core/thread processing unit to be allocated) and have set up a static threshold for alarming. 5 Seconds cannot be a real value but seems to be a summation value and it is not useful for monitoring porpoises.
We have figured out that the vmware probe wrongly collects aggregated data when the QOS_VMWARE_VM_CPU_READY_MS metric is enabled
Release : 20.4
Component : UIM - VMWARE 7.18
Wrong formula for the specific metric was coded into the probe:
Vmware 7.18:
<readyMS>
active = true
unit = ms
descr = This monitor indicates the time that the virtual machine was ready, but could not get scheduled to run on the physical CPU.
name_label = CPU Ready (milliseconds)
metric_type = 1.17.1:31
qos__mcs = QOS_VMWARE_VM_CPU_READY_MS
qos_pobc = QOS_VMWARE_VM_CPU_READY_MS
qos_orig = QOS_VMWARE_VM_CPU_READY_MS
pciKey = cpu+ready+summation
meth = [accum val]
type = perf
</readyMS>
Hotfix: vmware-7.1.8-20220713.095648-6.zip
<readyMS>
active = true
unit = ms
descr = This monitor indicates the time that the virtual machine was ready, but could not get scheduled to run on the physical CPU.
name_label = CPU Ready (milliseconds)
metric_type = 1.17.1:31
qos__mcs = QOS_VMWARE_VM_CPU_READY_MS
qos_pobc = QOS_VMWARE_VM_CPU_READY_MS
qos_orig = QOS_VMWARE_VM_CPU_READY_MS
pciKey = cpu+ready+summation
meth = [accum val]
type = perf
</readyMS>
The fix vmware-7.1.8-20220713.095648-6.zip attached to this KB contains an updated formula for the QOS_VMWARE_VM_CPU_READY_MS
Just deploying the probe fix is enough for the new formula to kick in and gather the new data without the "summation"