Monitor ESXi/VMware via SNMP
A hypervisor is a strange thing to monitor. The workloads you actually care about live inside the guests, but the health of every one of them rides on the host underneath. That's why SNMP ESXi monitoring earns its place: it reads the physical box — processors, memory, datastores, uplinks — from the outside, without an agent you have to install into a locked-down VMware kernel. This page covers whether ESXi speaks SNMP, what you can pull off it, how to turn the agent on, and why you'll want something watching the host from beyond its own network stack.
SNMP support on ESXi/VMware
Yes — ESXi ships with a native SNMP agent built into the host, and it has for a long time. You don't add a package. The agent is part of the hypervisor image; you just enable and configure it. It answers SNMPv1, SNMPv2c, and SNMPv3, which means you can start with a simple read-only community string on a trusted management network and graduate to authenticated, encrypted SNMPv3 when the host sits somewhere less friendly.
What the agent exposes is a useful mix. Standard trees come first — the Host Resources MIB (RFC 2790) for CPU, RAM and datastore capacity, the IF-MIB (RFC 2863) for physical uplinks, and the MIB-II system group (RFC 1213) for identity and uptime. On top of that VMware layers its own enterprise MIBs, which describe hypervisor-specific objects the standard trees never anticipated. When you monitor VMware SNMP the way most teams do, you lean on the standard MIBs for the numbers that matter day to day and reach for the vendor MIBs only when you need something they alone report.
There's a design decision worth understanding here. ESXi is a purpose-built, hardened hypervisor, not a general Linux box, so you don't get shell access to install and manage arbitrary monitoring agents inside it — and you wouldn't want to. The built-in SNMP agent is the sanctioned, low-footprint way to read host health without touching the kernel or risking your support status. That constraint is actually a gift: it forces a clean, standards-based approach instead of a pile of custom collectors, and it means the same poller you use for a switch or a server reads your hypervisor too.
One practical note before you configure anything: enabling the agent is only half the job. ESXi runs its own host firewall, and the SNMP service has to be allowed through it or your polls will simply vanish into the void. We'll cover that in the steps below.
What you can monitor on ESXi/VMware
The host-level metrics you'll reach for map cleanly onto standard OIDs, so almost any poller understands them without a custom MIB file. Here are the ones worth wiring up first.
| Metric | OID | MIB / standard |
|---|---|---|
| Host name / description | 1.3.6.1.2.1.1.1.0 (sysDescr) | MIB-II (RFC 1213) |
| Host uptime | 1.3.6.1.2.1.1.3.0 (sysUpTime) | MIB-II (RFC 1213) |
| Per-CPU load | 1.3.6.1.2.1.25.3.3.1.2 (hrProcessorLoad) | Host Resources MIB (RFC 2790) |
| Memory / datastore names | 1.3.6.1.2.1.25.2.3.1.3 (hrStorageDescr) | Host Resources MIB (RFC 2790) |
| Storage capacity | 1.3.6.1.2.1.25.2.3.1.5 (hrStorageSize) | Host Resources MIB (RFC 2790) |
| Storage used | 1.3.6.1.2.1.25.2.3.1.6 (hrStorageUsed) | Host Resources MIB (RFC 2790) |
| Uplink traffic (64-bit) | 1.3.6.1.2.1.31.1.1.1 (ifXTable) | IF-MIB (RFC 2863) |
| Uplink status / speed | 1.3.6.1.2.1.2.2.1 (ifTable) | IF-MIB (RFC 2863) |
Read that table as a starting kit, not a ceiling. Processor load comes back per logical CPU, so a host reports one row per core — the deeper mechanics live on the CPU utilization sensor page. Memory and datastores show up as rows in the same storage table, which is why local RAM, swap and each mounted datastore all surface through hrStorage*; the RAM/memory sensor and disk space usage pages unpack how to read a used-versus-size ratio into a percentage. For physical NICs, prefer the 64-bit ifXTable counters — a busy 10-gigabit uplink wraps the old 32-bit counters fast — and the interface traffic sensor explains the counter-delta math. Hypervisor-specific detail such as per-VM state or datastore-object health lives in VMware's own enterprise MIBs; load the vendor MIB when you need it rather than guessing at object numbers.
Enabling SNMP — steps
ESXi is configured from the host shell with esxcli. The exact flags shift slightly between versions, so confirm against VMware's documentation for the release you run, but the flow is stable:
- Set a community string for read-only v2c access:
esxcli system snmp set --communities public - Choose the listening port if you'd rather not sit on the default UDP 161:
esxcli system snmp set --port 161 - Enable the agent:
esxcli system snmp set --enable true - Open the host firewall so the SNMP service can actually receive polls:
esxcli network firewall ruleset set --ruleset-id snmp --enabled true - Verify from a management box with any Net-SNMP client:
snmpwalk -v2c -c public esxi-host.example.net 1.3.6.1.2.1.25.3.3.1.2
Prefer clicking? The vSphere Client exposes the same settings under the host's Configure → System area, and the change takes effect without a reboot. Whichever route you take, a few habits keep the host safe rather than exposed:
- Change the default UDP 161 when the host is reachable from anywhere untrusted — the custom port guide covers the reasoning.
- Publish only the OIDs you poll with an OID allowlist, which shrinks the attack surface and stops a curious scanner enumerating your whole hypervisor.
- Use SNMPv3 on any host not sitting behind an isolated management network, so the community string never crosses the wire in clear text.
If a walk comes back empty or hangs, the troubleshooting page works through the usual suspects — closed firewall ruleset, wrong community, wrong port.
Monitoring it externally
Here's the failure mode that catches people. Your monitoring VM runs on the cluster it's supposed to watch. The host wedges, storage goes read-only, an uplink flaps — and the very tool meant to warn you is sitting on the sick hardware, unable to send a thing. Internal monitoring has a structural blind spot: it shares fate with what it monitors.
Polling the host from outside removes that shared fate. An independent checker keeps reading sysUpTime and hrProcessorLoad across the network on its own schedule, so a host that has stopped answering is itself the alert. That's the principle behind double durability — and the broader case for agentless external monitoring is that a watcher which doesn't live on your infrastructure can't go down with it.
The maintenance argument reinforces the reliability one. A monitoring VM that rides on the cluster is one more thing you patch, migrate during host maintenance, and worry about when you're doing storage work — and it's blind during exactly those windows. An external checker sidesteps all of that: nothing to keep alive, nothing that competes for the resources you're trying to measure. It also gives you an honest outside view of reachability. Whether a host is actually answering from the network's perspective is a different question from whether an internal dashboard thinks it's fine, and on a hypervisor carrying dozens of workloads that difference is the whole game.
This is exactly what ostr.io Monitoring does for VMware SNMP: it polls your ESXi hosts from beyond your network as a zero-setup SaaS and fires real-time email and SMS alerts the moment a value crosses your threshold or the host stops responding — no collector VM to keep alive on the same cluster. Pointing it at a host is a quick add-endpoint flow.
