---
type: Article
title: "Monitor ESXi/VMware via SNMP"
description: "ESXi ships a native SNMP agent, so you read host CPU, memory, datastores and uplinks without installing anything into the VMware kernel. Setup and OIDs."
resource: "https://snmp-monitoring.com/devices/esxi/"
tags: [devices, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# 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.

![Diagram of an external SNMP poller reading hrProcessorLoad and datastore OIDs from a VMware ESXi host agent over UDP 161](https://snmp-monitoring.com/img/devices/esxi-snmp-poll.webp)

## 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](/sensors/server-resources/cpu-utilization.md). 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](/sensors/server-resources/ram-memory.md) and [disk space usage](/sensors/storage/disk-space-usage.md) 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](/sensors/network/interface-traffic.md) 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:

1. **Set a community string** for read-only v2c access:
   ```bash
   esxcli system snmp set --communities public
   ```
2. **Choose the listening port** if you'd rather not sit on the default UDP 161:
   ```bash
   esxcli system snmp set --port 161
   ```
3. **Enable the agent:**
   ```bash
   esxcli system snmp set --enable true
   ```
4. **Open the host firewall** so the SNMP service can actually receive polls:
   ```bash
   esxcli network firewall ruleset set --ruleset-id snmp --enabled true
   ```
5. **Verify** from a management box with any Net-SNMP client:
   ```bash
   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](/setup/custom-port.md) covers the reasoning.
- **Publish only the OIDs you poll** with an [OID allowlist](/setup/oid-allowlist.md), 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](/setup/troubleshooting.md) 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](/monitoring/double-durability.md) — and the broader case for [agentless external monitoring](/monitoring/agentless-external-monitoring.md) 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](https://ostr.io/service/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](/setup/add-endpoint-ostrio.md).

![Dashboard chart of ESXi host CPU load and datastore usage collected via SNMP over 24 hours with a threshold line](https://snmp-monitoring.com/img/devices/esxi-snmp-dashboard.webp)


## FAQ

**Does ESXi need a separate SNMP agent installed?**
No. The SNMP agent is built into ESXi. You enable and configure it with `esxcli system snmp` or through the vSphere Client — there's no package to add, and you should not try to install a general-purpose Linux daemon into the hypervisor.

**Why do my polls time out even though I enabled SNMP?**
Almost always the ESXi host firewall. Enabling the agent and opening the `snmp` firewall ruleset are two separate actions; miss the ruleset and every request is silently dropped. Enable it, then re-test with `snmpwalk`.

**Can I monitor individual virtual machines this way?**
Host-level SNMP reports the physical host — its CPU, memory, datastores and uplinks. For guest OS metrics you run SNMP inside each VM as you would on any [Linux](/devices/linux.md) or [Windows](/devices/windows.md) server. VMware's enterprise MIBs expose some per-VM state, but that's separate from what the guests report themselves.

**Should I use SNMPv2c or SNMPv3 on ESXi?**
v2c is fine on an isolated management network where the community string never crosses untrusted links. If the host is reachable more broadly, use SNMPv3 for authentication and on-the-wire encryption.

## Conclusion

SNMP ESXi monitoring comes down to a native agent you enable rather than install, standard OIDs that any poller already understands, and one easy-to-forget host-firewall rule. Turn the agent on with `esxcli`, publish just the OIDs you need, and read CPU, memory, datastores and uplinks straight off the hypervisor. Then put an independent watcher outside the cluster — because the one host you most need to hear about is the one too broken to tell you itself.