vSAN monitoring in the VMware Management Pack
What the vSAN MP discovers and monitors: 57 Skyline Health checks, performance monitors and 40 rules, prerequisites and ESA limits.
Applies to: OpsLogix VMware Management Pack (all versions) with the VMware vSAN Management Pack · SCOM 2019, 2022, 2025 · vCenter 7.0, 8.0, 9.0
Last updated: October 2026 · Reading time: 8 minutes
The VMware vSAN Management Pack (OpsLogix IMP - VMware vSAN Monitoring) adds vSAN objects, health checks and performance data on top of the VMware Management Pack. This article describes what it discovers, what it monitors and collects, what you need in vCenter, and its known limitations.
What gets discovered
The vSAN MP builds on the cluster, host and datastore objects from the VMware Management Pack. It adds the following classes:
| Class | One object per | Discovered from | Discovery interval |
| VMware vSan Service | vSAN-enabled cluster (named "vSanService <cluster name>") | VMware Cluster | 6 hours |
| VMware vSan DiskGroup | vSAN disk group (named "Disk group (<vSAN UUID>)") | VMware Cluster | About 6 hours |
| VMware vSAN Host Cache Disk | Cache-tier disk in a disk group | VMware ESX Server | About 6 hours |
| VMware vSAN Host Capacity Disk | Capacity-tier disk in a disk group | VMware ESX Server | About 6 hours |
| All VMware vSan Objects | One group with all vSAN objects | Group population | - |
The objects are linked to the rest of the VMware model like this:
- A VMware Cluster hosts its vSAN Service.
- The vSAN Service contains the vSAN datastore.
- The vSAN datastore hosts the disk groups.
- A disk group contains its cache disk and capacity disks.
- Each ESXi host hosts its own vSAN disks.
Because disk groups are hosted by the vSAN datastore, the datastore must be discovered by the VMware Management Pack first. On a new install, allow for the normal discovery cycle before the disk groups appear.
In the Monitoring workspace, the views are under VMware > vSAN. There are state and performance views for the vSAN Service, disk groups and disks, and an Open Alerts view.
Prerequisites
- VMware Management Pack configured. The vSAN MP uses the same vCenter connection and monitoring account. You don't enter separate credentials.
- Monitoring account. The same permissions as for the base MP: a read-only role with the Validate session privilege, assigned at the top level of vCenter. See Set up a VMware monitoring account.
- vSAN health API reachable. The collector calls the vSAN health service on the vCenter host over HTTPS (port 443), using the session of the monitoring account.
- vSAN Performance Service turned on. All performance monitors and rules read data from the vSAN performance service. If it is off, the vSAN objects are still discovered and the Skyline Health monitors still work, but there is no performance data. In the vSphere Client, check Cluster > Configure > vSAN > Services > Performance Service.
Skyline Health monitors
The MP has 57 monitors that each follow one vSAN Skyline Health test. They target the vSAN Service object (one per cluster) and all of them are on by default.
- Interval: every hour (3600 seconds).
- Health state: a green test result is Healthy. A red result is Critical. Any other result, such as yellow, is Warning.
- Alerts: raised from Warning, with a severity that matches the health state. They close automatically when the test turns green. The alert includes the test name, its result and the details vCenter reports.
- If vCenter doesn't report a particular test for your vSAN version, that monitor gets no data and keeps its current state.
In the console every display name starts with "SkyLine Health". The table below leaves that prefix out and groups the tests by area to make the list easier to read.
| Area | Count | Skyline Health tests |
| Network | 9 | vSAN cluster partition · Hosts with connectivity issues · Hosts disconnected from VC · Network latency check · vSAN: Basic (unicast) connectivity check · vSAN: MTU check (ping with large packet size) · vMotion: Basic (unicast) connectivity check · vMotion: MTU check (ping with large packet size) · All hosts have a vSAN vmknic configured |
| Data and objects | 4 | vSAN object health · Component metadata health · vSAN max component size · Resync operations throttling |
| Hardware compatibility | 10 | vSAN HCL DB up-to-date · vSAN HCL DB Auto Update · SCSI controller is VMware certified · Controller is VMware certified for ESXi release · Controller driver is VMware certified · Controller firmware is VMware certified · Controller disk group mode is VMware certified · vSAN firmware provider health · vSAN firmware version recommendation · vSAN release catalog up-to-date |
| Physical disks and capacity | 12 | Operation health · Disk capacity · Congestion · Component limit health · Component · Memory pools (heaps) · Memory pools (slabs) · Disk space · Disks usage on storage controller · Read cache reservations · vSAN Disk Balance · What if the most consumed host fails |
| Cluster configuration | 11 | vSphere cluster members match vSAN cluster members · vSAN cluster configuration consistency · Advanced vSAN configuration in sync · vSAN extended configuration in sync · vSAN daemon liveness · vCenter state is authoritative · Time is synchronized across hosts and VC · Software version compatibility · Disk format version · Host compliance check for hyperconverged cluster configuration · VDS compliance check for hyperconverged cluster configuration |
| Performance service | 5 | Stats DB object · Stats master election · Performance data collection · All hosts contributing stats · Stats DB object conflicts |
| Health service, updates and online health | 6 | ESXi vSAN Health service installation · vSAN Health Service up-to-date · Advisor · vSAN Support Insight · vSAN Build Recommendation Engine Health · vSAN build recommendation |
Performance and state monitors
These monitors run every 5 minutes (300 seconds) and are all on by default. A single sample is enough to change the state. A value above the warning threshold sets Warning, and a value at or above the critical threshold sets Critical. Alerts are raised from Warning and close automatically. You can override both thresholds.
| Monitor | Target | Warning | Critical |
| vSAN Cluster Used Capacity Percent | vSAN Service | 95% | 99% |
| vSAN Backend Read Latency microseconds | vSAN Service | 40,000 µs (40 ms) | 80,000 µs (80 ms) |
| vSAN Backend Write Latency microseconds | vSAN Service | 40,000 µs | 80,000 µs |
| vSAN Backend Congestion | vSAN Service | 50 | 200 |
| vSAN Backend Outstanding IO | vSAN Service | 2 | 10 |
| vSAN VM Congestion | vSAN Service | 50 | 200 |
| vSAN VM Outstanding IO | vSAN Service | 2 | 10 |
| vSAN Diskgroup Capacity Used | Disk group | 95% | 98% |
| vSAN Diskgroup Outstanding Write OPs | Disk group | 7,000 | 9,500 |
| vSAN Cache Disk Device Average Latency microseconds | Cache disk | 40,000 µs | 80,000 µs |
| vSAN Cache Disk Guest Average Latency microseconds | Cache disk | 40,000 µs | 80,000 µs |
| vSAN Capacity Disk Device Average Latency microseconds | Capacity disk | 40,000 µs | 80,000 µs |
| vSAN Capacity Disk Guest Average Latency microseconds | Capacity disk | 40,000 µs | 80,000 µs |
Two more monitors check availability:
- vSAN Disk Operational State (cache and capacity disks, every 5 minutes): "ok" is Healthy, "error" is Critical, anything else is Warning.
- Diskgroup to Disk Availability State Rollup: a disk group takes the worst availability state of its disks.
Performance collection rules
The MP has 40 performance rules. All are on by default, run every 5 minutes, and write to both the operational database and the data warehouse.
| Group | Target | Rules | What is collected |
| Disk group frontend | Disk group | 6 | Frontend read and write IOPS, read and write throughput, read and write latency |
| Disk group cache | Disk group | 2 | Read Cache Hit Rate, Write Buffer Free Percentage |
| Disk group capacity | Disk group | 3 | Capacity, Used Capacity, Reserved Capacity |
| Disk latency | Cache and capacity disks | 4 | Guest Average Latency and Device Average Latency per disk tier |
| VM perspective | vSAN Service | 8 | Read and write IOPS, read and write throughput, read and write latency, congestion, outstanding IO, as seen by the VMs |
| Backend perspective | vSAN Service | 6 | Read and write IOPS, throughput and latency on the vSAN backend |
| Resync and recovery | vSAN Service | 6 | Resync read and recovery write IOPS, throughput and latency (backend) |
| Cluster capacity | vSAN Service | 5 | Total, free and used capacity in bytes; used and free capacity in percent |
In performance views, the cluster capacity counters "Used Capacity" and "Free Capacity" each appear twice. The instance name tells them apart: bytes or percent.
Known limitations
vSAN ESA (Express Storage Architecture) isn't supported. The MP discovers disk groups and disks from the disk-group layout that vSAN OSA (Original Storage Architecture) uses. ESA clusters don't use disk groups, so on an ESA cluster:
- No disk group, cache disk or capacity disk objects are discovered. This is expected; it doesn't mean discovery failed.
- The disk group and disk monitors (capacity used, outstanding writes, disk latency, disk operational state) and the 15 disk group and disk performance rules have no objects to run on.
The following parts don't depend on disk groups and keep running on an ESA cluster:
- The vSAN Service object is discovered for every cluster where vSAN is turned on.
- The Skyline Health monitors read the cluster health summary. Tests that vCenter doesn't report for an ESA cluster get no data.
- The cluster-level performance monitors and rules (VM perspective, backend perspective, resync and recovery, cluster capacity) query cluster-wide counters. We haven't confirmed every counter on ESA. If vCenter doesn't return a counter, that rule or monitor collects nothing.