VMware

VMware is assigned IANA private enterprise number 6876. SNMP monitoring in a VMware environment involves two separate components: the SNMP agent on each ESXi host, and SNMP trap forwarding configured on vCenter Server.

SNMPv1 and SNMPv2c (communities)

On an ESXi host, SNMP is configured with the esxcli system snmp command (or the older vicfg-snmp utility), which writes its configuration to /etc/vmware/snmp.xml:

esxcli system snmp set --communities public
esxcli system snmp set --targets 192.168.1.100@162/public
esxcli system snmp set --enable true

A corresponding firewall rule must be enabled to allow SNMP traffic on ESXi 5.0 and later.

SNMPv3

SNMPv3 on an ESXi host is also configured through esxcli system snmp set, using a different set of flags:

esxcli system snmp set --enable true
esxcli system snmp set -a SHA1 -x AES128
esxcli system snmp hash --auth-hash <password> --priv-hash <password> --raw-secret
esxcli system snmp set --users userid/<auth-hash>/<priv-hash>/priv

-a sets the authentication protocol and -x the privacy protocol. The esxcli system snmp hash subcommand converts a plaintext password into the hash values the --users flag expects - it does not accept a plaintext password directly. The --users flag then associates a username with its hashed authentication and privacy secrets and a security level (priv, auth, or none).

Sending traps

Trap destinations on an ESXi host are set with the --targets flag shown above, for either SNMP version. vCenter Server's own trap forwarding is configured separately, in the vSphere Client under [vCenter instance] > Configure > Settings > General > Edit > SNMP receivers. Up to four receivers can be configured there, each with its own enable checkbox, receiver address, UDP port, and community string, independent of each host's own agent configuration.

Platform differences

The SNMP agent built into ESXi answers polls for the VMware-specific MIBs described below, and VMware bundles standard HOST-RESOURCES-MIB and IF-MIB files for use alongside them - though VMware's own documentation describes these files as intended for use alongside the VMware MIBs rather than stating outright that the embedded agent answers every object in those standard trees. vCenter Server, by contrast, does not expose its own inventory for direct SNMP polling at all; it only forwards its alarms as traps, through a separate trap-sending service, to the receivers configured above.

Common OIDs and MIBs

VMware-specific objects are defined under enterprises.6876 (1.3.6.1.4.1.6876) in VMWARE-ROOT-MIB. Virtual machine inventory is reported in VMWARE-VMINFO-MIB, under 1.3.6.1.4.1.6876.2.1.1: vmwVmDisplayName (.2), vmwVmMemSize (.5), vmwVmState (.6), vmwVmCpus (.9), and vmwVmUUID (.10), each indexed by vmwVmIdx (.1).

Host-level resource counts are reported in VMWARE-RESOURCES-MIB, including vmwNumCPUs (1.3.6.1.4.1.6876.3.1.1), vmwMemSize (1.3.6.1.4.1.6876.3.2.1), and vmwMemAvail (1.3.6.1.4.1.6876.3.2.3). Hardware health status, derived from IPMI sensor data, is reported separately in VMWARE-ENV-MIB, and vCenter alarm and event traps are defined in VMWARE-VC-EVENT-MIB. VMware also publishes VMWARE-ESX-AGENTCAP-MIB, VMWARE-CIMOM-MIB, VMWARE-PRODUCTS-MIB, and VMWARE-TC-MIB alongside these. VMWARE-SYSTEM-MIB, which previously defined host-identification objects such as vmwProdName and vmwProdVersion, is marked obsolete in VMware's own documentation; the standard SNMPv2-MIB objects sysDescr.0 and sysObjectID.0 are the current recommended replacement for host identification instead.

Gotchas

In vCenter Server 8.0 Update 2 and later, SNMPv3 traps can fail to send because the FIPS-compliant trap-sending component rejects configuration created under the older SHA1/MD5-based authentication used by earlier vCenter versions. This is documented as a known issue (Broadcom knowledge base article 369459) and requires a manual workaround rather than a configuration change alone.

A separate, unrelated issue affects the SNMP service itself: applying certain vCenter 7.0 and 8.0 patches has been documented to leave the snmpd service disabled or stopped after the patch completes, silently breaking both polling and trap delivery until it is manually re-enabled and started (Broadcom knowledge base article 379893). Current ESXi versions also no longer send SNMP traps for physical disk failures; Broadcom documentation describes this as intended behavior, with IPMI-sourced hardware events (memory, power supply, fan, CPU) still covered, but physical-disk failures left to vCenter alarms or a storage controller's own alerting instead (Broadcom knowledge base article 432011).