Is the CPU usage of the VMs reported as ~80% (Say in task manger)?
is the CPU use constant?
Disable any AV services and see if this helps. Also check for any hardware agents that may still be in place since the P2V.
Welcome to the forums,
Did you remove all the hardware vendor related drivers / services? Also if you changed from multiple physical cpu's to 1 virtual cpu did you revert the HAL?
VMware Communities User Moderator | VCP | VCDX
If you find this information useful, please award points for "correct" or "helpful".
No thoughts? I'm experiencing this problem too and while it doesn't appear to be affecting the performance of the host (we have CPU to spare) I'd still like to figure out why..
Is it a specific service that is up the CPU resources? If yes, which one?
I've seen it many times with McAfee 7.1 where the cpu on the VM maxes out. A workaround is to restart the AV service. A fix is to upgrade to version 8.+
Not for me. The virtual machine shows virtually no CPU usage whatsoever so I can't pin it down to a specific service. Both the VI Client and esxtop tell a different story and show, at times, 100% utilization on both CPUs. I suspect it has something to do with the HAL or the fact that it has multiple CPUs. It is using the correct HAL but it was converted from a 2 x CPU with hyperthreading so Windows previously thought it had 4 CPUs.
It isn't critical that I address this because this VM will be decommissioned in the next several months, but I'm still curious and would like to address it.
I got this from VM Support:
When an operating system is idle, it enters its idle loop. If the idle loop executes a halt instruction on the CPU, CPU resources are released. In the case of a physical machine, this release typically results in lower power consumption. In the case of a virtual machine, the release results in idle CPU resources which can then be retasked for use by other active virtual machines.
On some Windows, the OS spins in the idle loop for a longer time before executing the halt instruction. When the system is virtualized, this results in increased physical CPU utilization even when there is no substantial activity in the guest operating system.
you can try to override this idle loop handler's behavior on a per-virtual machine basis by adding or modifying the following virtual machine configuration (.vmx) file option and assigning a value for n between 100 and 4000:
monitor.idleLoopSpinUS = "n"
Values outside of this range are unlikely to result in resource utilization improvements. In comparison with the default value:
- A lower value means that the virtual machine is halted more quickly and uses fewer physical CPU cycles when idle.
- A higher value means that the virtual machine is allowed to spin longer before being halted.
The advantage of allowing the virtual machine to spin longer in the idle loop prior to being halted by the VMkernel is that the transition of a virtual machine to active state (executing code other than the idle loop) occurs far quicker from idle state than from halted state. As a result, lowering the value can reduce guest operating system performance and responsiveness in certain circumstances, such as with workloads that have time-sensitive, I/O-intensive, or interactive requirements, which cycle often between idle and active.
I would suggest to try 100, 4000 and -1 (in order to let the OS choose the best value).
In order to set up the monitor.idleLoopSpinUS parameter you can edit the vmx file while the VM is powered off or:
Shut down the virtual machine
Click Edit Settings on the Virtual Machine Summary Page to access the virtual machine Settings Page.
Click the Options tab and choose Advanced.
Click Configuration Parameters. The Configuration Parameter window appears.
Click Add Row.
Enter monitor.idleLoopSpinUS as Name and -1 , for example as Value. Click OK.
If after trying the 3 options still doesn't fix the issue:, I will need to get the logs of the ESX with support data on them:
Please, let me know if it works.
Pretty sure your VMs with problems have more than one vCPU. When you "downgrade' the VMs to use a single CPU (and adjust the HAL accordingly), I am sure the problem will go away. If they have sufficient CPU power then, just leave them at a single vCPU. If you need more than one vCPU, you could try to add a vCUP back, and change the HAL again. Hopefully the issue will stay away then, although I have seen several times that the problems return then.
Because windows 2000 hosts are often older machines anyway, a single vCPU on modern (ESX) hardware works ok most of the time... Just try to go back to one vCPU for now, first see if that fixes the issue. Then decide waht to do next
Visit my blog at http://erikzandboer.wordpress.com
At least in my situation the physical server had multiple CPUs and when converted to a virtual machine we kept the dual CPUs and HAL. I'm sure the multiproc configuration has something to do with it because other Win2k servers that were P2V'ed do not show this behavior. The only thing that changed was that it went from 4 CPUs (2 hyperthreaded physical CPUs) to 2 vCPUs.
Right. If your W2K VM allows for it, go back to one vCPU. The excessive CPU usage will then disappear (after you adjust the HAL). Question of course is: Does the VM have sufficient CPU power having only one vCPU. I would try this out first, all customers I have seen who had this problem got a better performance after going from 2 to 1 vCPU!
Visit my blog at http://erikzandboer.wordpress.com