About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
A hosted Windows server feels slow. Task Manager inside it shows the processor at 40 per cent. The hosting provider's dashboard shows the virtual machine at 70 per cent, or shows nothing unusual at all. Both may be correct, because they measure different things from different places.
This article explains what each view can and cannot see, the hypervisor figures to check when a server is slow, and how to use both views together.
Why it matters
A disagreement between the two views can turn a fault into an argument. The customer says the server is starved; the provider says the server is idle. Knowing what each figure measures turns that into a question both sides can answer with data.
How it works
What the guest cannot see
Windows inside a virtual machine measures time on its virtual processors. It cannot see the time when one of its virtual processors was ready to run but the hypervisor had not given it a physical processor. During that time, from the guest's point of view, nothing happened.
Broadcom states the problem plainly: dynamic resource allocation can make obtaining accurate information about the resource utilization (CPU utilization, in particular) of individual virtual machines, or applications running within virtual machines, difficult.
Hypervisor figures for CPU on VMware
Broadcom's esxtop documentation defines the figures the host keeps for each VM. The one that shows whether a server is waiting for the host is ready time:
- %RDY is the percentage of time the resource pool, virtual machine, or world was ready to run, but was not provided CPU resources on which to execute.
- %MLMTD is the share of time the host deliberately did not run the VM because running it would exceed its limit setting. Broadcom explicitly includes this limited time in %RDY. A high limited-time figure identifies cap-induced waiting; it does not rule out contention occurring as well.
- %RUN reports scheduled time. %USED reports CPU use with host-system work and overlap accounting; CPU frequency can also affect its relationship to %RUN. Confirm counter scope and sampling interval before comparing them.
Broadcom's documentation also notes that on a host with hyperthreading enabled, %RUN can be twice as large as %USED. Figures from the provider's tools and from the guest therefore need the same definitions before they are compared.
Hypervisor figures for memory on VMware
The host can take memory back from a VM. Broadcom's memory panel definitions include:
- MCTLSZ, the amount of physical memory reclaimed from the VM by ballooning, a balloon driver inside the guest (Broadcom names the vmmemctl module) that asks Windows to release memory; the panel also shows whether that driver is installed.
- SWCUR, current host swap use for the VM, and swap-in and swap-out rates.
Ballooned memory looks to Windows like memory in use by a driver. Host swapping is invisible to Windows: the guest sees its memory as present while the host may be reading parts of it back from disk.
VMware counters inside Windows
Broadcom states that VMware-specific performance objects are loaded into Windows Performance Monitor when VMware Tools is installed. Their object names begin with "VM", and Broadcom describes them as giving application administrators accurate VM resource figures from within Performance Monitor. For a customer without access to the host, they are a direct route to host-side figures.
Hyper-V
Microsoft's guidance on detecting bottlenecks in a virtualised environment names separate counters for the host and the guest. On the host, the Hyper-V Hypervisor Virtual Processor counters' total run time describes each virtual processor's use; Microsoft suggests action when that figure is over 90 per cent. For memory, Microsoft lists Available MBytes on the host and inside the VM, and explains that low available memory inside the VM calls for more memory or a higher Dynamic Memory maximum.
What to choose and why
To diagnose a slow server, collect both views over the same period:
- Inside the guest: processor time, processor queue length, available memory and disk latency, recorded in Performance Monitor at the time of the slowdown.
- From the provider: CPU ready time or its Hyper-V equivalent, any limit-related figure, ballooned memory and host swapping for the VM over the same period.
- Compare CPU evidence. High ready time means the VM waited, but includes limit-induced waiting. Compare %RDY and %MLMTD on the same scope and interval, and inspect VM/resource-pool caps before attributing host contention. High guest CPU with low ready time calls for checking workload efficiency and whether extra processors would help.
- Compare memory evidence. Ballooning or host swapping shows reclamation, not its cause. Check actual host pressure and VM/resource-pool limits and reservations. Broadcom documents ballooning from misconfigured resource-pool settings even when the host or cluster has resources available. Keep configured VM memory, host-consumed memory and guest-available memory distinct.
| Guest shows | Host shows | Writer's reading |
|---|---|---|
| CPU moderate, server slow | High ready time | Scheduling wait; compare limit-induced time and effective caps before concluding host contention |
| CPU moderate, server slow | High limit-related time | A configured cap is holding the VM back |
| CPU high | Low ready time | The VM needs more resources, or the workload needs tuning |
| Memory in use by a driver | Ballooning | The host is reclaiming memory; check both physical pressure and VM/resource-pool policy |
Questions to ask a provider:
- Can you show CPU ready time, any limit-related time, ballooning and host swapping for my VM for a given period?
- Is a limit set on my VM's CPU or memory?
- Can VMware Tools counters be read inside my server, or can you provide equivalent reports?
Risks and limits
- Thresholds vary. Broadcom's documentation defines these figures but, in the pages cited here, does not set a single threshold for ready time. Ask the provider what it treats as normal.
- Averages hide peaks. A one-hour average can hide a five-minute stall. Compare short intervals around the slowdown.
- The guest's own figures still matter. Disk latency and application queues may be the cause, with the host working normally.
- Counter names and units differ between platforms and tools. Confirm the definition before comparing two figures.
- No commands are given here. The sources show where the counters are found.
Sources
Opened 14 November 2026.
- Broadcom TechDocs: Monitoring Guest Operating System Performance, vSphere 8.0.
- Broadcom TechDocs: Enable Statistics Collection for Guest Operating System Performance Analysis, vSphere 8.0.
- Broadcom TechDocs: CPU Panel, esxtop, vSphere 8.0.
- Broadcom TechDocs: Memory Panel, esxtop, vSphere 8.0.
- Microsoft Learn: Detecting bottlenecks in a virtualized environment; displayed Last updated: 2022-05-19.
Related service: Managed support.
Related future topics
- Noisy neighbours in a shared cloud: what a tenant can measure.
- Host maintenance and live migration: what your VM notices.
- Right-sizing a hosted Windows server.
Learning notes
- The guest cannot see time spent waiting for the host.
- On VMware, ready time includes limit-induced waiting; correlate both figures and their scope before blaming host contention.
- Ballooning and host swapping show reclamation; host pressure and VM/resource-pool policies are alternative causes to check.
- VMware Tools adds VM counters to Windows Performance Monitor.
- Compare both views over the same short interval before drawing conclusions.
This article was originally published on .