VMware (ESXi / vCenter)

The VMware (ESXi / vCenter) check connects to an ESXi host or vCenter Server and reports the state of the virtualization infrastructure: host alerts, virtual-machine power states, VM snapshots, datastore capacity, and host hardware temperature. octoja talks to vSphere directly via the vSphere SOAP API — no separate management agent on the ESXi/vCenter host is required. The check runs on an octoja agent on Windows, macOS, or Linux (each in x64 and Arm64 builds) that can reach the vCenter / ESXi endpoint, every 5 minutes; the interval is not user-configurable. Point it at a standalone ESXi host for small sites, or at vCenter for multi-host clusters.

Prerequisites

• An ESXi host or vCenter Server reachable over HTTPS from the octoja agent's network
• The octoja agent installed on any device (Windows, macOS, or Linux) that can reach the vCenter / ESXi address — the host being monitored does not need an agent
• A vSphere user with at least Read-only role on the inventory you want monitored

Use a dedicated read-only user. The check needs read access only. Create a user in vSphere (or use SSO) with the built-in Read-only role assigned at the inventory level you want covered — host, cluster, datacenter, or root.

Steps

You can assign the check to a network device as well as to an agent device.

If the ESXi host or vCenter Server is already in octoja as an agentless network device, add the check on that device instead: open it and choose Checks → Add Check → VMware (ESXi / vCenter). octoja supplies the address from the device's IP, so the Host field is hidden, and the agent set as its Monitoring asset runs the check. You still enter Username and Password in the check; the VMware credentials and VMware API port stored on the network device are not used, and the check connects over HTTPS on port 443. See Add a Network Device Without an Agent.

1. Make sure the octoja agent is installed on a device that can reach the vCenter / ESXi management address.
2. Go to Devices and open that device.
3. Click the Checks tab → Add Check → VMware (ESXi / vCenter).
4. Enter Host, Username (e.g. administrator@vsphere.local for vCenter, root for an ESXi host) and Password. Leave Ignore SSL certificate errors on for typical vCenter / ESXi installations with self-signed certificates; turn it off only if you have replaced the certificate with one signed by a trusted CA.
5. Under What to monitor, choose which areas to monitor, and adjust the thresholds for the areas you turned on.
6. Click Add Check.

After the first check interval, the result appears in the device's Checks tab with KPI tiles for VMs / datastores / alerts, per-datastore usage bars, and a Temperature section listing each host's hottest reading and every sensor it reports.

Settings

If a warning threshold is set above its matching critical threshold, the check silently swaps the two values at runtime. This applies to the datastore, snapshot, and intake-air pairs.

Monitored areas

Each check run reads up to five areas from the inventory; each can be turned on or off independently:

• Host alerts — hosts that are disconnected, not responding, or powered off
• VM states — total VM count, count of running (powered-on) VMs, and any suspended VMs
• VM snapshots (off by default) — age of each VM's oldest snapshot against your snapshot thresholds, and VMs that need consolidation
• Datastore usage — capacity, free space, and used percentage per datastore against your warning and critical thresholds. The thresholds apply globally to every datastore; per-datastore overrides are not currently supported.
• Hardware temperature — every temperature sensor an ESXi host reports through its BMC / IPMI. Each sensor is graded by the health state the host firmware sets. The intake-air thresholds only apply to sensors whose name contains inlet or ambient (for example System Board Inlet Temp, 01-Inlet Ambient, Ambient Temp). Every other sensor — CPU die, DIMM, power supply, voltage regulator — runs hot by design and is judged solely by the firmware health state, so a CPU running at 78 °C stays green.

Results

The worst result across the active areas becomes the overall check status.

• A host produces at most one alert per run. The host conditions in the table above are evaluated in that order and the first match wins, so a host that is powered off and also reports overall status yellow is reported once, as Powered off.
• If the check cannot retrieve a VM's snapshot data, it returns Failure.
• The device Checks tab visualises datastore usage history with dashed lines marking the warning and critical thresholds, aggregates repeated host alerts into an Alert events list, and plots a Peak temperature history per host.

Metrics collected

Per check run:

• Virtual machines — running count out of the total inventory (shown as "Virtual machines x/y running")
• Datastores — datastore count, plus per-datastore capacity in GB, free space in GB, used %, and computed severity
• Alerts — list of host alerts (name, status text, entity name, severity)
• Problem VMs — list of suspended VMs (name, power state, severity)
• Snapshot problems — list of VMs with a snapshot finding (name, snapshot count, age of the oldest snapshot in days, consolidation needed, severity)
• Host temperatures — per host with sensors, every temperature sensor it reports (sensor name, °C, host-reported health state, severity), hottest first, plus the rolled-up severity for the host

Tips

• Point a single check at vCenter rather than at each ESXi host individually when you have a cluster. The check will see every host and every VM under that vCenter in one place. For a multi-vCenter estate, configure one check per vCenter; the check does not federate across vCenters.
• For very large estates, run datastore monitoring on its own check (with VMs and hosts off) and a separate check for hosts and VMs. That way you can tune storage alerting separately from host alerting.
• If the check times out, the inventory may be too large to query within the 30-second limit per vSphere request. Grant the vSphere user read access only to the hosts, clusters, and datastores you actually want monitored — a smaller scope keeps queries fast.
• The SOAP session is opened, queried, and closed within each check interval — the agent does not maintain a long-lived connection.