VMware ESXi and vSphere Cluster Management
Monitor Disk Latency and Storage Usage on VMware ESXi
Learn how to use vCenter performance charts to monitor ESXi disk latency, compare VMkernel and physical-device delays, and investigate storage bottlenecks.
Disk-intensive workloads can overload storage resources and make virtual machines feel slow. Database operations, file services, backups, snapshots, and batch processing can all generate substantial storage I/O. Monitoring disk latency on an ESXi host helps determine whether delays originate in the host storage-processing path or in the physical storage infrastructure.
This lesson uses vCenter Server and the vSphere Web Client to configure a real-time performance chart for an ESXi host. You will compare Kernel command latency with Physical device command latency.
Why Monitor ESXi Disk Performance?
Storage latency is the delay experienced while storage I/O requests are processed and completed. ESXi storage requests use the SCSI command model, in which a SCSI command represents a storage I/O request issued through a storage device or path.
When storage resources are saturated or slow, virtual machines may show delayed database queries, slow file operations, application timeouts, or generally poor responsiveness. Host-level disk monitoring helps separate storage symptoms from problems involving other resources.
| Resource area | Typical concern | What disk latency helps establish |
|---|---|---|
| CPU | High processor usage or CPU scheduling delays | Whether the observed delay is instead associated with storage processing |
| Memory | Memory pressure, swapping, or reclamation | Whether storage I/O is independently showing elevated delay |
| Network | Packet loss, congestion, or high network latency | Whether the storage path has a separate performance problem |
| Storage | Queueing, device contention, or slow completion | Where storage-related delay may be occurring |
The VMkernel is the ESXi kernel component responsible for managing host resources, including storage I/O processing. Host-level latency counters can therefore help identify whether time is being spent in the ESXi processing path or while the physical device completes the request.
Disk Latency Counters
Kernel command latency
Kernel command latency is the average time a SCSI command spends being processed in the VMkernel. It represents host-side storage-processing time and is measured in milliseconds (ms).
Physical device command latency
Physical device command latency is the average time required for the underlying physical storage device to complete a SCSI command. It is also measured in milliseconds.
Review these counters together rather than treating either counter as a complete diagnosis. Their relationship helps indicate whether delay is primarily associated with ESXi processing, the physical device, or the broader storage path.
| Counter | What It Measures | Potential Concern Threshold | Likely Area for Further Investigation |
|---|---|---|---|
| Kernel command latency | VMkernel time per SCSI command | Greater than approximately 2 ms | ESXi host storage-processing path |
| Physical device command latency | Device completion time per SCSI command | Greater than approximately 15 ms | Physical storage device or storage path |
Access Host Performance Charts in vCenter
vCenter Server is the centralized VMware management platform used to view and manage ESXi performance data. The vSphere Web Client provides the interface for configuring performance charts.
- Select the relevant ESXi host in the vCenter inventory.
- Open Monitor.
- Open Performance.
- Switch to the Advanced performance view.
- Open the chart options or chart configuration interface.
- Choose Disk as the metric category.
Interface labels can differ slightly between vSphere releases, but the required workflow is to select the host, open its advanced performance charts, and configure disk-related counters.
Configure a Real-Time Disk Latency Chart
A real-time performance chart focuses on current or recently collected performance data. It is useful when a slow workload is active or when you want to observe a suspected intermittent problem.
| Setting | Recommended Selection | Purpose |
|---|---|---|
| Metric category | Disk | Exposes disk performance counters |
| Timespan | Real-time | Supports immediate troubleshooting |
| Chart type | Line Graph | Shows changes and spikes over time |
| Object selection | Target ESXi host and relevant disk controller | Targets the applicable storage resources |
| Counters | Kernel command latency and Physical device command latency | Compares host-side and device-side delay |
- In the advanced performance chart configuration, set the timespan to Real-time.
- Set the chart type to Line Graph.
- Select the target ESXi host.
- Select the applicable disk controller or storage controller object.
- Add Kernel command latency.
- Add Physical device command latency.
- Apply the selections and inspect the resulting graph.
The disk controller is the host storage controller object for which disk performance counters can be selected. Confirm that the selected controller is associated with the storage activity you are investigating.
Interpret the Latency Graph
Compare both lines during quiet periods and busy periods. Look for three characteristics: the absolute latency value, the difference between the counters, and the duration of any elevation.
High physical-device latency
If Physical device command latency rises significantly while Kernel command latency remains comparatively low, investigate the physical storage device and the storage transport path. Possible areas include the storage array, device queues, SAN path, fabric, or other connected storage infrastructure.
Elevated kernel-command latency
If Kernel command latency is elevated, investigate the ESXi host storage-processing path and controller-related conditions. Compare it with physical-device latency to determine whether the physical device is also reporting delay.
Both counters rise together
When both latency lines increase during the same period, the environment may be under broad I/O pressure. A busy device can cause device completion delays while the host also spends more time processing queued storage work.
Short spikes versus sustained elevation
Short, isolated spikes may correspond to a backup, batch job, snapshot operation, or other high-I/O event. Sustained elevation is more concerning, especially when it exceeds the reference thresholds and coincides with user-visible service impact.
Practical Monitoring Examples
Establish a baseline
Configure a real-time disk latency chart during a known low-activity period. Record typical Kernel command latency and Physical device command latency values. This baseline gives you a comparison point for busy periods and future incidents.
Investigate a slow virtual machine workload
When an application reports slow database or file operations, open the host disk chart while the workload is active. Inspect both latency counters, note when they change, and determine whether the values remain above the reference levels. Sustained elevation justifies further investigation of the storage path.
Separate host-path and device delays
If physical-device latency rises substantially but kernel-command latency stays comparatively low, focus first on the storage device, array, SAN path, or fabric. If kernel latency is elevated, examine host-side storage processing and controller conditions as well.
Detect intermittent contention
Use the line graph to identify short latency spikes. Correlate their timestamps with scheduled backups, batch processing, snapshots, maintenance operations, or other high-I/O jobs.
Troubleshooting Patterns
Physical device command latency remains above 15 ms
The underlying storage device or storage transport path may be slow or overloaded.
- Determine whether the elevation is sustained or occurs only during workload peaks.
- Check storage array, device, path, and fabric health with the appropriate infrastructure monitoring tools.
- Identify concurrent I/O-heavy workloads that correlate with the event.
Kernel command latency exceeds 2 ms
Storage I/O may be delayed in the ESXi host processing path.
- Compare kernel latency with physical-device latency.
- Confirm that the correct host and disk controller object are selected.
- Check for workload-driven spikes and recurring time-based patterns.
Both latency counters rise during the same period
The storage environment may be experiencing broad I/O pressure, with delays visible in both host-side processing and device completion.
- Identify high-I/O applications or scheduled operations active at that time.
- Compare the event with normal baseline levels.
- Investigate the host, controller, and shared storage layers as appropriate.
Short, isolated spikes appear
A transient workload burst or scheduled process may be causing temporary contention.
- Correlate timestamps with backups, batch jobs, maintenance, or application activity.
- Check whether users or applications experienced performance degradation at the same time.
- Prioritize remediation if spikes become frequent, sustained, or associated with service impact.
Operational Checklist
- Select the affected ESXi host in vCenter.
- Open Monitor, Performance, and the Advanced view.
- Choose the Disk metric category.
- Use a Real-time timespan and Line Graph chart.
- Select the host and applicable disk controller.
- Add Kernel command latency and Physical device command latency.
- Compare the lines with the host's normal baseline.
- Use approximately 2 ms for kernel latency and 15 ms for physical-device latency as investigation triggers.
- Correlate elevated values with workload activity and the duration of the event.
- Extend investigation to the ESXi host, controller, storage path, fabric, and array layers based on the counter behavior.
For a broader storage monitoring workflow, continue with monitoring disk usage and compare capacity observations with latency behavior.