VM CPU utilization in VC very different than in OS

[Ivan_Drago]

Hi, I have this weird issue. In Virtual Center a VM shows that it is utilizing close to 100% CPU. However when I go into the server, it's at 0-4%. I know that this VM is not utilized heavily and VC is wrong. But this affects the host, DRS, and so on.

Has anyone encountered this before. I don't even know where to begin troubleshooting this. The VM is assigned 2 CPUs and 1024 RAM. It's on a host that has more than enough resources available.

Thanks.

[williambishop]

Check and see if somehow a limit has been set on the vm. How are you verifying you have enough resources remaining on the server?

[Ivan_Drago]

In VC it shows how much CPU and RAM is being used. Plus, this is a monster box with 4 quad procs and 64 gig ram running only 15 VMs right now. There no setting for limiting this particular VM. It seems like it's strictly some kind of disconnect between VC and the VM.

[mike_laspina]

Hello,

I would investigate the following possibilities.

1) Management agent not working correctly - Restart service

service mgmt-vmware restart

2) While loop in code that creates abnormal CPU utilization stats - Stop running processes until the symptom subsides.

3 Known issue with DRS

Disable DRS and if the CPU returns to norm then look at this link.

http://kb.vmware.com/kb/1003638

Message was edited by: Ken.Cline to shorten the URL

[jhanekom]

When it comes to actual (physical) utilisation metrics, VirtualCenter utilisation stats is always more reliable than the guest OS's performance counters, as it has more information to go on; it measures the actual utilisation of the process at the vmkernel level, while the guest OS measures its perceived utilisation based on how many timeslices it thinks it used up on the CPU.

What guest OS are you running? What HAL is the guest OS using? If you run esxtop on the console, are you seeing high (greater than 15%) %READY times next to any of your VMs consistently?

[piercelynch]

If I remember rightly, in VC performance graphs there are two seperate units being measured for CPU usage - one as a percentage, and the other usage in MHz. I think, if I remember rightly.. and this might be wrong, but that 100% may only be lets say 1000MHz usage at peak, as opposed to say 2000MHz of the total processing power available.

My advice would be to look at the Usage in Units reading first, before the percentage to get a better idea of what is really happening.

Hope that helps just don't hold me to that one!

P.

[BigHug]

What's your guest OS? Since the guest has 2 vcpu's, make sure it has multiprocessor HAL if windows.

[serracon_suppor]

(re)install vmware tools to the guest

apply fixes to the guest

check for a 3rd party idle process. vmware task scheduling relies on a halt instruction when guest is idle. some guest os dont do this in default. (Windows does by default)

check for maleware and rootkit in the guest

trust ESXTOP. if this says 100% CPU it IS 100% CPU. Then the VM is lying to you. find the reason. Most causes are NOT wanted guest actions.....

[Ivan_Drago]

All of your suggestions have been checked. ESXTOP is showing 150-160%used. (2 CPUs). I checked the HAL and it's set up for 2 CPUs. %RDY is normal, 2-3%.

The windows task manager shows no processes are running that would do this. Shows IDLE process at 99%. The VM is not heavily utilized, but there is defenetelly something there. I did the DRS check, and nothing changed.

Are there any more suggestions I can try. Thanks all.

[jhanekom]

Ivan, what guest OS is this?

[Ivan_Drago]

It's windows 2000.

[BigHug · Accepted solution]

Since the guest is windows 2000 and you have checked everything, try to set monitor.idleLoopSpinUS to a lower number in the vmx file.

[Ivan_Drago]

BigHug, thanks for the suggestion. I put in a value of "1000" and the VMs and ESX top are down to almost no utilization. Which pretty much frees up 2 of my host's CPUs.

Thanks to everyone to their input.

[BigHug]

Good to hear that help. Keep monitor your guest. We have to set it to "100" to get rid of the problem. Also after move to VI 3.5, the problem seems to be go away.