claudio/VSC
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Issue

Browse Source 
Code backup
This commit is contained in:
Claudio
2026-05-10 16:59:01 +02:00
commit 368d6fafea
796 changed files with 315310 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Icinga2/_Test/vSan Mib/vmw/notifications.txt
+273
View File
@@ -0,0 +1,273 @@
Document: SNMP Agent Notifications for VROPS, VRNI, NSX Manager, and ESXi and Virtual Center
Security: none
Author: mrm@vmware.com <Michael R. MacFaden>
Date: : Mon Dec 16 10:29:18 PST 2019
Version: 1.15
Source: http://kb.vmware.com/kb/2054359
Introduction:
Notifications on VROPS, VRNI, ESXi, NSX, TUNNEL, and VCSA are composed from IETF standard
and VMWARE enterprise MIB module documents. ESXi may also generate 3rd party notifications
from any vib/CIM providers installed. They may generate OEM events using their enterprise oids.
VRNI MIB modules were reimplemented in 3.9 release and reused existing oids are are thus
not backward compatible and will conflict if both versions of mib modules are imported into same managment
system. The obsolete/ directory contains prior VRNI mib modules.
VROPS MIB modules switched to new oids in 7.0 release and replaced
VMWARE-VCOPS-EVENT-MIB.mib which is now obsolete.
VMWARE-TUNNEL-MIB and its snmp agent capability mib are described here:
https://docs.vmware.com/en/Unified-Access-Gateway/3.6/com.vmware.uag-36-deploy-config.doc/GUID-F71E6283-E24B-49F5-8AC6-D28915CD41AD.html
All ESX VMware MIB modules are compatible back to ESX 2.0, always load the latest set to
manage all vesions of ESXi and ESX Classic. The VMWARE-OBSOLETE-MIB contains any obsolete
objects and would be loaded when running older versions of software. See the VMWARE-*-AGENTCAP-MIB
for which releases of code provide what versions of MIB modules.
Virtual Center has two snmp agents in Virtual Center Appliance starting in 6.x release cycle.
VC Daemon presently only supports SNMPv1. VCSA supports SNMPv1/v2c/v3.
Here is a summary of the MIB modules that define notifications which are sent on the wire
as either SNMPv1 Trap Protocol data units (PDUs) or SNMPv3 Trap PDU for VCSA and ESXi,
NSX only supports V2c traps in its first release. See their VMWARE-NSX-AGENTCAP-MIB for details.
Example output is also provided.
Configuring notifications:
William Lam wrote up how to configure trap/inform here for ESXi.
http://blogs.vmware.com/vsphere/2012/11/configuring-snmp-v1v2cv3-using-esxcli-5-1.html
Documentation for VCSA SNMP agent:
VCSA https://pubs.vmware.com/vsphere-60/topic/com.vmware.vsphere.vcsa.doc/GUID-3695CE84-C6DF-497E-BA4E-2B341CC366C5.html
Documentation, 5.1, 5.5, 6.0 for CLI
http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.monitoring.doc%2FGUID-346CDDC6-8928-466F-A356-C8DAA6112439.html
Configuring NSX: https://www.vmware.com/support/pubs/nsx_pubs.html
Current VMware KB Aricles on SNMP:
* Downloading MIB modules http://kb.vmware.com/kb/1013445
* Listing of all OIDs by type, mib module and name: http://kb.vmware.com/kb/2054359
* Debugging notification (trap/inform) reception http://kb.vmware.com/kb/2035445
* Configuring SNMPv3 inform remotre users in ESXi SNMP agent: http://kb.vmware.com/kb/2033377
* Reverse Poll Feature aka SNMP Trap is repeated every 5 minutes http://ikb.vmware.com/kb/2020271
* Timeouts and SNMP https://ikb.vmware.com/kb/2100602
* Timeouts in ESXi snmp in storage apis: https://ikb.vmware.com/kb/2105674
* Understanding Layer 2 networking as reported by ESXi SNMP http://kb.vmware.com/kb/2118059
* Monitoring VCSA using SNMP (2145018) http://kb.vmware.com/kb/2145018
VMworld 2016 information:
http://blogs.vmware.com/vsphere/2016/08/vmworld-2016-vcenter-server-sessions.html
Session Title: Understand the role SNMP agents play in a VSPHERE Stack
http://vmware.mediasite.com/mediasite/Play/4eab4abb038344f98c2c1e6ef8b7e2fa1d?catalog=dbf1ec28-2557-4dd3-a381-e5fe4ceabc40
Since ESXi 5.x, snmp agent should now be configured with 'esxcli system snmp' instead of vicfg-snmp
script. the vicfg-snmp script is found on VCSA appliance in the bash shell and snmp.set command
in the appliancesh shell.
vicfg-snmp will continue to work. The vicfg-snmp uses VIM API objects will only ever support SNMPv1.
The command line flags have been preserved from the RCLI to esxcli
this allows for easy substitution of 'vicfg-snmp' to 'esxcli system snmp' for example:
esxcli system snmp --hwsrc sensor
esxcli system snmp --no traps <oid[,oid]> # see list of oids in Appendix A below
esxcli system snmp set -t 192.0.2.1/mytesttrapcom --enable 1 # turn on snmp agent and sent traps to one destination.
# SNMPv3 support for informs has been available since ESX 5.1, with no security (noAuthNoPriv)
# is equivalent to SNMPv1
# To define a user and inform target for that user
esxcli system snmp set -u john_doe/-/-/none -i 192.0.2.1@1162/john_doe/none/inform
Configuring notifications with RCLI command (ESX 3.x to ESX 5.0):
First one provides a backward compatibility switch for VMWARE-ENV-MIB for ESX
releases prior to 5.0 use the cmd:
vicfg-snmp --hwsrc sensors # switch to pre-ESXi 5.0 notifcation format
Second, one can now filter out/stop sending notifications. Just provide the
oid in the form enterprise.0.trapid
vicfg-snmp --notraps 1.3.6.1.4.1.6876.1.0.302,1.3.6.1.4.1.6876.1.0.303
ESXi NOTIFICATIONS:
SNMPv2-MIB (http://www.ietf.org/rfc/rfc3418.txt)
coldStart -- sent when ESX reboots
warmStart -- sent when vmware-hostd process restarts
IF-MIB (http://www.ietf.org/rfc/rfc2863.txt)
linkDown -- Physical interface changed to down state
linkUp -- Physical interface changed to down state
When one receives these notifications, they will contain the ifIndex which
when used to poll the ifTable shall see the following
managed objects change state: ifLastChange, ifSpeed, ifOperStatus change state)
VMWARE-VMINFO-MIB
vmPoweredOn TRAP-TYPE
VARIABLES { vmID, vmConfigFile, vmDisplayName }
DESCRIPTION
"This trap is sent when a virtual machine is powered on from a suspended
or a powered off state. The origin of this event can be several:
for instance may be operator initiated, existing vmx process reconnects to control subsystem.
NOTE: vms powered up due to VMotion are not reported. Upon receiving this notification client applications should
poll the vmwVmTable to obtain current status."
::= 1
vmPoweredOff TRAP-TYPE
VARIABLES { vmID, vmConfigFile, vmDisplayName }
DESCRIPTION
"This trap is sent when a virtual machine is powered off. The origin of this event can be several:
for instance may be operator initiated, vmx process terminating abnormally. NOTE: vms powered down due
to VMotion are not reported. Upon receiving this notification client applications should
poll the vmwVmTable to obtain current status."
::= 2
vmHBLost TRAP-TYPE
VARIABLES { vmID, vmConfigFile, vmDisplayName }
DESCRIPTION
"This trap is sent when a virtual machine detects a loss in guest heartbeat. The Guest heartbeat
is only sent if VMware Tools are installed in the Guest OS. Control process will send this event whenever it
determines the number of guest heartbeats for a given period of time have not been received.
Upon receiving this notification client applications should
poll the vmwVmTable to obtain current status."
::= 3
vmHBDetected TRAP-TYPE
VARIABLES { vmID, vmConfigFile, vmDisplayName }
DESCRIPTION
"This trap is sent when a virtual machine detects or regains the required number of guest heartbeats
for a given period of time. This is only sent if VMware tools are installed in the Guest OS.
Upon receiving this notification client applications should
poll the vmwVmTable to obtain current status."
::= 4
vmSuspended TRAP-TYPE
VARIABLES { vmID, vmConfigFile, vmDisplayName }
DESCRIPTION
"This trap is sent when a virtual machine is suspended. The origin of this event may be several: operator
initiated, by software api clients, and by other means.
Upon receiving this notification client applications should
poll the vmwVmTable to obtain current status."
::= 5
VMWARE-CIMOM-MIB
The sfcbd agent in ESXi starting in ESX 5.0 will send a heartbeat once every
5 minutes. This duration can be changed or disabled within sfcbd or filtered
at the snmp agent (see Appendix A)
vmwCimOmHeartbeat TRAP-TYPE
VARIABLES { vmwEnvIndicationTime }
DESCRIPTION
"This notification, if the agent is so configured, will be sent
on a periodic basis to indicate cimom indication delivery is functioning."
::= { vmwCimOmNotifications 401 }
Update the sfcbc configuration etc/sfcb/sfcb.cfg" and add the key "heartbeatInterval"
to the number of seconds it should be sent.
VMWARE-ENV-MIB
Starting with ESXi 5.0, VMware enterprise hardware related notifcations are reported in
the specific identifier field of SNMPv1 trap PDU as follow:
VMWARE-ENV-MIB vmwEnvHardwareEvent notification 1.3.6.1.4.1.6876.0.301
VMWARE-ENV-MIB vmwESXEnvHardwareEvent notification 1.3.6.1.4.1.6876.4.1.0.301
VMWARE-ENV-MIB vmwESXEnvHardwareAlert notification 1.3.6.1.4.1.6876.4.1.0.302
VMWARE-ENV-MIB vmwESXEnvBatteryAlert notification 1.3.6.1.4.1.6876.4.1.0.303
VMWARE-ENV-MIB vmwESXEnvChassisAlert notification 1.3.6.1.4.1.6876.4.1.0.304
VMWARE-ENV-MIB vmwESXEnvThermalAlert notification 1.3.6.1.4.1.6876.4.1.0.305
VMWARE-ENV-MIB vmwESXEnvDiskAlert notification 1.3.6.1.4.1.6876.4.1.0.306
VMWARE-ENV-MIB vmwESXEnvPowerAlert notification 1.3.6.1.4.1.6876.4.1.0.307
VMWARE-ENV-MIB vmwESXEnvProcessorAlert notification 1.3.6.1.4.1.6876.4.1.0.308
VMWARE-ENV-MIB vmwESXEnvMemoryAlert notification 1.3.6.1.4.1.6876.4.1.0.309
VMWARE-ENV-MIB vmwESXEnvBIOSAlert notification 1.3.6.1.4.1.6876.4.1.0.310
An example:
2010-06-11 19:59:34 promc-2n-dhcp119.eng.vmware.com [10.20.104.119] (via UDP: [10.20.104.119]:50569) TRAP, SNMP v1, community mrm-pc
.1.3.6.1.4.1.6876.4.1 Enterprise Specific Trap (302)
Uptime: 0:22:06.22
.1.3.6.1.4.1.6876.4.30.10 = STRING: RawIpmiProvider
.1.3.6.1.4.1.6876.4.30.9 = STRING: 44454c4c-5700-1035-8038-b4c04f594231
.1.3.6.1.4.1.6876.4.30.8 = Wrong Type (should be INTEGER): 2
.1.3.6.1.4.1.6876.4.30.7 = STRING: root/cimv2:OMC_DiscreteSensor.DeviceID="81.0.32.2",CreationClassName="OMC_DiscreteSensor",SystemName="44454c4c-5700-1035-8038-b4c04f594231",SystemCreationClassName="O MC_UnitaryComputerSystem"
.1.3.6.1.4.1.6876.4.30.6 = STRING: OMC_UnitaryComputerSystem
.1.3.6.1.4.1.6876.4.30.5 = Wrong Type (should be INTEGER): 5
.1.3.6.1.4.1.6876.4.30.4 = Wrong Type (should be INTEGER): 0
.1.3.6.1.4.1.6876.4.30.3 = STRING: 12848-49-55,48:55:49.49,148:515552534648555648505143484848
.1.3.6.1.4.1.6876.4.30.2 = STRING: 12848-49-55,48:55:49.49,148:515653544648484848484843484848
.1.3.6.1.4.1.6876.4.30.1 = STRING: Assert + Event Logging Disabled Log area reset/cleared
Environmental/hardware related notifications in VMWARE-ENV-MIB are the same content as found in ESXi CIM Indications.
Prior to ESXi 5.0, this is the trap one would get:
vmwEnvHardwareEvent TRAP-TYPE
VARIABLES { vmwSubsystemType, vmwHardwareStatus, vmwEventDescription, vmwEnvHardwareTime }
DESCRIPTION
"This notification, if the agent is so configured, may be sent when
the ESX Operating System has detected a material change in
physical condition of the hardware"
::= 301
This generic notification depends on the CIM subsystem mappings to discrete IPMI sensors.
For example on a Dell R805, one might see one or more alarms as follows:
2007-11-01 16:15:42 esx014.eng.vmware.com [10.17.21.14] (via 10.17.21.14) TRAP, SNMP v1, community private
SNMPv2-SMI::VMWARE-PRODUCTS-MIB::vmwESX Enterprise Specific Trap (301) Uptime: 0:00:06.76
VMWARE-ENV-MIB::vmwSubsystemType.1 = INTEGER: unknown(1)
VMWARE-ENV-MIB::vmwHardwareStatus.1 = INTEGER: critical(4)
VMWARE-ENV-MIB::vmwEventDescription.1 = STRING: "USB Over-current 65 for BIOS 1"
VMWARE-ENV-MIB::vmwEnvHardwareTime.1 = Timeticks: (675) 0:00:06.75
External RAID enclosure configured to RAID 5, pull cable from one of the disk and this is sent:
2007-11-14 10:11:15 scho1-dev.eng.vmware.com [10.20.110.134] (via 10.20.110.134) TRAP, SNMP v1, community private
VMWARE-PRODUCTS-MIB::vmwESX Enterprise Specific Trap (301) Uptime: 0:03:11.14
VMWARE-ENV-MIB::vmwSubsystemType.1 = INTEGER: raidController(9)
VMWARE-ENV-MIB::vmwHardwareStatus.1 = INTEGER: marginal(3)
VMWARE-ENV-MIB::vmwERING: "RAID1 Virtual Disk 0 of Controller 0"
VMWARE-ENV-MIB::vmwEnvHardwareTime.1 = Timeticks: (19114) 0:03:11.14
NOTE: Given the specific hardware above for example
one would next consult the Dell R805 Dell's documentation
on IPMI messages for the majority of those listed (not all):
http://support.dell.com/support/edocs/software/svradmin/5.5/en/MSG/html/msgch30.htm
EXAMPLES:
2007-11-01 16:14:11 NET-SNMP version 5.1.2 Started.
# hostd is rebooted while ESX is up, a warmStart trap is sent...
2007-11-01 16:14:36 esx014.eng.vmware.com [10.17.21.14] (via 10.17.21.14) TRAP, SNMP v1, community private
SNMPv2-SMI::VMWARE-PRODUCTS-MIB::vmwESX Warm Start Trap (0) Uptime: 0:00:00.02
vSPHERE Center Server Notifications
VMWARE-VC-EVENT-MIB:
vmwVCNotifications OBJECT IDENTIFIER ::= {vmwVC 0}
vpxdAlarm NOTIFICATION-TYPE
OBJECTS { vmwVpxdTrapType, vmwVpxdHostName, vmwVpxdVMName,
vmwVpxdOldStatus, vmwVpxdNewStatus, vmwVpxdObjValue }
STATUS current
DESCRIPTION
"This trap is sent when entity alarm status changed."
::= { vmwVCNotifications 201 }
vpxdDiagnostic NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"This trap is sent on starting or restarting vCenter Server,
on requesting a test notification explicitly, and can also be
configured to be sent periodically at a specified time interval via
vCenter Server configuration."
::= { vmwVCNotifications 202 }
The vpxdAlarm notification is transmitted from vCenter Server on changes in
alarm state, dictated by the trigger and notification configuration of the
alarm.
The vpxdDiagnostic notification is used for generating test traps as well as
generating coldStart traps for vCenter Server starts/restarts.
The transmission of test traps can be configured through the vCenter Server
OptionManager interface, or through the vCenter configuration file (vpxd.cfg),
using the following keys:
snmp.testTrap.periodic.enable ("true"/"false")
snmp.testTrap.periodic.period (defaults to 300) (Number of milliseconds)
snmp.coldStartTrap.enable (defaults to "true") ("true"/"false")
# end of Document