Virtual machine monitoring tracks CPU, memory, disk I/O, and network I/O per VM, plus guest OS metrics that the hypervisor cannot see. The team that monitors VMs well catches memory leaks before OOM kills the process, disk pressure before the filesystem fills, and CPU saturation before the hypervisor throttles. The team that monitors poorly has VMs that crash overnight, alerts that fire after users complain, and post-incident reviews that say ‘we should have seen this coming’.
Table of contents
- What the hypervisor can see (and what it cannot)
- CPU monitoring
- Memory monitoring
- Disk I/O monitoring
- Practical setup
- FAQ
What the hypervisor can see (and what it cannot)
The hypervisor sees resource allocation and utilization per VM: CPU time consumed, memory allocated vs used, disk I/O operations per second, network bytes in and out. This is enough to detect overall pressure but not enough to see inside the VM. The team that monitors only hypervisor metrics sees ‘this VM is using 95% CPU’ but not which process is consuming it.
The guest OS sees process-level details: which process is using CPU, which process is using memory, which files are open, which sockets are active. This is enough to debug specific issues but not enough to see VM-vs-VM contention. The team that monitors only guest metrics misses the case where the host is oversold and every VM is slow because of neighbor contention.
The right approach is both: hypervisor metrics for capacity planning and contention detection, guest metrics for application-level debugging. The team that runs both has the full picture. The team that runs only one has blind spots that show up at the worst time.
CPU monitoring
Track CPU utilization per VM, broken down by user, system, iowait, and steal time. User CPU is application work. System CPU is kernel work. Iowait is CPU waiting for disk. Steal time is CPU the VM wanted but the hypervisor gave to another VM - the most important metric for VM performance on shared hosts.
Steal time above 5% means the VM is CPU-starved. The hypervisor gave CPU time to other VMs, and this VM waited. The team that sees sustained steal time above 5% has an oversubscribed host. The fix is to migrate VMs to other hosts, reduce vCPU allocation per VM, or scale up the host.
CPU saturation (run queue length) matters more than CPU utilization. A VM at 80% CPU with a short run queue is fine. A VM at 30% CPU with a long run queue is overloaded (because each process is waiting for CPU time). The team that watches run queue length catches CPU pressure that utilization alone misses.
Memory monitoring
Track memory used vs memory allocated per VM. A VM with 4GB allocated but only 2GB used has headroom; a VM with 4GB allocated and 4GB used (with no swap) is about to OOM. The team that monitors memory pressure catches leaks before the OOM killer fires.
Watch swap usage. A VM that swaps to disk is thrashing - the kernel is moving memory pages to disk because RAM is full, then back to RAM when the process needs them. The team that sees swap activity above 0% on a steady-state workload has a memory problem (either under-sized VM or memory leak).
Balloon drivers (virtio-balloon) let the hypervisor reclaim memory from VMs. The hypervisor asks the guest to give back memory; the guest’s balloon driver inflates to release pages. The team that runs balloon drivers has more flexible memory management; the team that disables balloon drivers has fixed memory allocation per VM.
Disk I/O monitoring
Track IOPS, throughput, and latency per VM per disk. IOPS is operations per second. Throughput is MB/s. Latency is the time per operation. The team that monitors all three sees the full disk performance picture; the team that monitors only one dimension misses the others.
Storage contention on shared storage shows up as latency spikes. When multiple VMs hit the same physical disk, each VM’s latency goes up because the disk can only handle so many operations per second. The team that sees correlated latency spikes across VMs on the same host has a storage contention problem - either move VMs to other hosts or upgrade the storage.
Watch for disk full conditions. A disk at 90% full is a warning. A disk at 100% full is an outage. The team that monitors disk usage with a 75% warning and 90% critical threshold has time to clean up before the disk fills. The team that monitors disk only at 95% has outages.
Practical setup
Run the hypervisor’s metrics exporter. KVM with libvirt exposes per-VM metrics through libvirt’s API. The team that runs Prometheus with the libvirt exporter has hypervisor-level metrics in a standard format. VMware vSphere exposes metrics through vCenter; Hyper-V through WMI.
Run a guest OS exporter. node_exporter (Prometheus) on Linux guests, windows_exporter on Windows guests. The team that runs these exporters has guest-level metrics (process, filesystem, network) in the same Prometheus format as the hypervisor metrics.
Build dashboards that show both layers. One panel for hypervisor metrics (resource allocation, steal time, IOPS), one panel for guest metrics (process list, filesystem usage, network connections). The team that has both layers visible catches issues that single-layer monitoring misses.
FAQ
What is steal time in a VM?
Steal time is the percentage of CPU time the VM wanted but the hypervisor gave to another VM. High steal time (above 5%) means the host is oversubscribed. The team that monitors steal time catches oversubscription before users complain about slow VMs.
Do I need a monitoring agent inside the VM?
Yes, for application-level visibility. Hypervisor metrics show resource allocation but not which process is consuming it. The team that runs node_exporter or windows_exporter inside the VM gets process-level metrics that the hypervisor cannot see.
What is the difference between VM monitoring and container monitoring?
Container monitoring runs inside the container (or on the host with cgroup-aware tools). VM monitoring runs at two levels: the hypervisor (resource allocation) and the guest OS (process-level). The team that runs containers has simpler monitoring (one layer); the team that runs VMs has two layers to correlate.
How do I monitor VMware vSphere VMs?
VMware vCenter exposes metrics through its API. The team that runs the vSphere exporter for Prometheus, or uses VMware Aria Operations (the commercial product), has VM metrics in a standard format. vRealize Network Insight adds network-layer visibility on top.
What metrics should I alert on for VMs?
Alert on: CPU steal time above 5% for 5 minutes, memory usage above 90%, disk usage above 90%, disk I/O latency above 100ms for 5 minutes, network errors above baseline. Do not alert on CPU utilization alone - steal time and run queue are better signals.
Can I monitor VMs without an agent?
Partially. The hypervisor sees CPU, memory, disk I/O, and network I/O without an agent inside the VM. The team that needs process-level visibility (which process is using CPU, which files are open) must install an agent in the guest OS.
How this fits the rest of the stack
For a sense of what the full project costs before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the worker, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
Useful related references: