How is virtual server monitoring different from physical server monitoring?
Virtual server monitoring adds the hypervisor layer, making troubleshooting more complex than with physical servers. A VM shares CPU, memory, storage, and network resources with other VMs on the same host. So, a VM may appear healthy while its performance is affected by an overloaded or resource-constrained host.
A complete virtualization monitoring strategy hence must look beyond individual VMs. For VMware environments, monitor three layers together:
- Virtual machine: CPU, memory, disk, and network performance.
- ESXi host: Resource utilization, contention, and overall host health.
- Datastore: Capacity, latency, and I/O performance.
This layer-wise view helps identify issues that can affect multiple VMs, such as host resource contention or a datastore running out of space.
Note: This page covers VMware vSphere monitoring specifically. For Hyper-V environments,see the Hyper-V monitoring guide.
What are the key metrics to monitor in VMware vSphere?
Monitoring VMware vSphere requires visibility at both the VM and ESXi host levels. These metrics help identify performance bottlenecks, resource contention, and hardware issues before they affect workloads.
VM-level metrics
| Metric | What it measures | Why it matters |
|---|---|---|
| CPU Ready (%) | How long a VM is ready to run but waiting for physical CPU resources | Sustained values above 5% can indicate CPU contention at the host level. |
| Memory Balloon (MB) | Memory reclaimed from the VM by the hypervisor | Indicates that the host is under memory pressure and reclaiming allocated RAM. |
| Memory Swap (MB/s) | Rate at which VM memory is swapped to disk | High swap activity can significantly reduce VM performance and indicates memory overcommitment. |
| Disk Read/Write Latency (ms) | Time taken to complete virtual disk operations | High latency can indicate datastore or underlying storage contention. |
| Network Throughput (Mbps) | Inbound and outbound traffic through the VM's virtual NIC | Changes from the normal baseline can indicate workload changes or unusual network activity. |
Note: Monitoring network throughput at the VM’s virtual NIC level can miss issues at the virtual switch layer. In environments using distributed virtual switches (dvSwitch), monitor port group bandwidth utilization and dropped packets at the switch level as well. These metrics can reveal network saturation affecting multiple VMs on a segment, even when individual VM metrics appear normal. For environments with significant east-west VM traffic, include dvSwitch performance counters from vCenter in the monitoring setup.
ESXi host-level metrics
| Metric | What it measures | Why it matters / alert point |
|---|---|---|
| CPU Utilization (%) | Overall processor usage across VMs on the host | Sustained usage above 80% can increase CPU contention and VM CPU Ready time. |
| Memory Utilization (%) | Host memory consumed by running VMs and the hypervisor | Usage above 90% increases the risk of ballooning and swapping. |
| CPU Overcommit Ratio | vCPUs assigned compared with available physical CPU cores. | Higher ratios can increase CPU contention when workloads peak. |
| Hardware Health | Temperature, fans, power supplies, and other physical components. | Hardware warnings can affect every VM running on the host and require immediate attention. |
Datastore-level metrics
Storage can become a shared bottleneck in vSphere environments because multiple VMs often use the same datastore. Monitoring the datastore helps identify I/O contention and capacity issues that may not be visible from individual VM metrics.
| Metric | Alert threshold |
|---|---|
| Datastore space used (%) | >75% warning; >85% critical |
| Datastore read/write latency (ms) | >20 ms warning; >50 ms critical |
| Datastore IOPS | Establish a baseline and alert when sustained IOPS exceed 120% of the normal level |
Note: The 75% / 85% space thresholds above apply to physical datastore utilization. With thin-provisioned VMs, total committed capacity, the amount all VMs could potentially consume can exceed the physical space available. Monitor both physical utilization (current usage) and committed capacity (maximum potential usage). A datastore at 60% physical utilization but 150% committed capacity could still run out of space if multiple VMs grow simultaneously.
How does VMware monitoring collect data?
VMware monitoring usually collects data through the vCenter Server API. This gives the monitoring tool access to performance and health data for ESXi hosts, VMs, datastores, and resource pools from one place.
- No agents on VMs: Data is collected through vCenter instead of installing an agent on every VM.
- One connection: A vCenter account can provide visibility across the VMware environment.
- Automatic updates: New VMs are detected automatically when they are created, moved, or removed.
- Centralized monitoring: You can monitor hosts, VMs, and datastores without setting up each one separately.
If you use standalone ESXi hosts without vCenter, the monitoring tool can connect directly to the host API, but with fewer automation and inventory capabilities.
What should you monitor in VMware beyond physical server metrics?
Snapshot buildup
- Old or large VM snapshots can consume datastore space and slow disk performance.
- Monitor snapshot age and size for each VM.
- Consider alerting when a snapshot is older than 72 hours or exceeds 10 GB.
vMotion and DRS activity
- vMotion and Distributed Resource Scheduler (DRS) can move VMs between hosts to balance workloads.
- These migrations can sometimes cause short-term performance changes.
- Correlating migration events with VM performance metrics can help explain sudden or temporary slowdowns.
Host overcommitment
- Multiple VMs share the same physical CPU resources, so a host can have more assigned vCPUs than physical CPU cores.
- For example, 24 vCPUs running on 8 physical cores creates a 3:1 overcommit ratio.
- Monitor the ratio alongside CPU Ready time to identify when CPU overcommitment is affecting VM performance.
vSphere HA and cluster events
- Host heartbeat loss: Monitor host heartbeat loss events to detect host failures that may trigger HA recovery actions.
- HA restart events: Track VM restarts initiated by vSphere HA after a host failure, distinguishing them from normal VM restarts.
- Admission control warnings: Monitor warnings when the cluster lacks sufficient capacity to guarantee HA restarts for all running VMs.
How does OpManager monitor VMware environments?
OpManager connects to vCenter Server through its API to monitor the VMware environment from a single console. You can monitor ESXi hosts, VMs, datastores, clusters, and resource pools alongside physical servers and network devices.
- Automatic discovery: OpManager discovers the VMware inventory and maps relationships between VMs, hosts, and datastores.
- Prebuilt monitoring: VMware templates provide ready-to-use performance monitors and thresholds, reducing manual configuration.
- VM performance visibility: Monitor CPU Ready, memory ballooning, swapping, and datastore latency along with standard CPU, memory, disk, and network metrics.
- Unified monitoring: View VMware and physical infrastructure together, making it easier to identify whether an issue is within a VM, host, datastore, or the wider infrastructure.
For standard server performance metrics alongside VMware-specific ones,see key server performance metrics. For monitoring VMware alongside cloud instances in a hybrid environment, see how to monitor servers in hybrid environments.
FAQs on virtual and VMware server monitoring
How is virtual server monitoring different from physical server monitoring?
Virtual server monitoring looks at three connected layers: the VM, the hypervisor host, and the shared datastore. A VM may appear healthy while experiencing CPU contention, memory pressure, or storage latency at the host or datastore level. Physical servers do not have these shared virtualization layers.