VMware ESXi and vSphere Cluster Management
Configure Email and SNMP Alarm Notifications in VMware vCenter Server
Learn how to configure SMTP email and SNMP trap notifications in vCenter Server, assign actions to alarms, test delivery, and troubleshoot common failures.
vCenter Server alarms can detect defined conditions in the vSphere environment and perform actions when those conditions occur. Notification actions help administrators learn about problems quickly, route alerts to an on-call team, and integrate vSphere events with centralized monitoring or ticketing systems.
Notification configuration has two separate parts:
- Delivery infrastructure: vCenter Server mail settings define how email is relayed, and SNMP receiver settings define where traps are sent.
- Alarm definition: The alarm selects the action, recipient, and alarm state or trigger that causes the notification.
Configuring an SMTP server or SNMP receiver alone does not cause every alarm to send a notification. An alarm must also contain the corresponding action.
Notification methods supported by vCenter alarms
vCenter alarms can use one or more notification actions, depending on the required workflow.
- Email notification: vCenter Server sends an alarm message through a configured SMTP server to one or more specified recipients.
- SNMP trap: vCenter Server sends an unsolicited SNMP notification to configured SNMP receivers. A monitoring platform can interpret the trap, correlate it with other events, or create a ticket.
Prerequisites and planning
Before changing settings, identify the vCenter Server instance that owns the alarms. You also need the following information:
Confirm DNS resolution, routing, and firewall access between vCenter Server and each endpoint. The mail relay may require vCenter Server to be approved as a permitted client or may impose sender restrictions. The monitoring team may require a specific SNMP port, source address, protocol configuration, or receiver-side registration.
Configure vCenter Server email notification settings
- Open the vSphere Client, the management interface for vCenter Server and its inventory.
- In the inventory, select the target vCenter Server object.
- Open Manage, then General.
- Choose Edit vCenter Server Settings.
- Open the Mail section.
- Enter the SMTP server hostname or address.
- Enter the sender account or email identity that vCenter Server should use for alarm messages.
- Save the settings.
These are global mail-delivery settings for that vCenter Server. They provide the relay and sender information used when an alarm contains an email notification action. They do not, by themselves, select alarm conditions or recipients.
Email example
For a critical infrastructure alarm, configure the approved mail relay and an operations sender identity. Then add an email action to the alarm and specify the virtualization operations mailbox or on-call distribution list as the recipient.
Configure vCenter Server SNMP receiver settings
- Select the target vCenter Server in the vSphere Client inventory.
- Open the vCenter Server general settings editor through Manage, General, and Edit vCenter Server Settings.
- Open the SNMP Receivers section.
- Add the monitoring server hostname or address.
- Enter the destination port on which that receiver listens for traps.
- Repeat the process for additional monitoring destinations when required.
- Save the settings.
vCenter Server supports up to four SNMP receivers. Alarm SNMP actions use the receiver destinations configured here. The receiver must be prepared to accept and process traps from the vCenter Server.
SNMP example
Add the organization’s monitoring platform as an SNMP receiver, then assign an SNMP trap action to an alarm. When the alarm action runs, the monitoring platform can display the event, correlate it with other data, or create an automated ticket.
Assign notification actions to an alarm
- Open the alarm definition wizard for a new alarm, or edit an existing alarm.
- Define or review the condition, trigger, and inventory scope for the alarm.
- Open the Actions page.
- Add an email notification action and specify recipient addresses where applicable.
- Add an SNMP trap action when the alarm should notify configured SNMP receivers.
- Associate each action with the relevant alarm state or trigger condition. For example, an action might run when a condition becomes critical or when the alarm status changes.
- Review the definition and save it.
An alarm can contain both actions. A combined workflow might send an email to the on-call team while also sending an SNMP trap to centralized monitoring or automated ticketing.
Validation and operational testing
Use a controlled test alarm or another safe, non-production condition. Avoid testing by deliberately causing a production outage.
- Trigger the test condition and confirm that the alarm enters the state associated with its actions.
- For email, verify arrival, sender identity, recipient delivery, subject and body content, and spam or quarantine behavior.
- For SNMP, verify that the monitoring platform receives the trap and interprets it as the expected event.
- Confirm that the alert identifies the affected vSphere object, alarm name, condition, and severity or state.
- Record the notification endpoints, alarm owner, service owner, and escalation recipients.
For a combined workflow, verify both paths independently. Successful email delivery does not prove that SNMP delivery works, and receipt of an SNMP trap does not prove that the mail relay is configured correctly.
Notification design considerations
- Choose meaningful thresholds and state transitions. Poorly tuned alarms can generate excessive messages and cause alert fatigue.
- Use email for direct human notification, especially for an on-call team or service owner.
- Use SNMP traps for centralized monitoring, event correlation, and automated ticketing.
- Consider multiple recipients, on-call routing, and monitoring redundancy for important services.
- Keep SMTP and SNMP endpoint information current when mail relays, monitoring platforms, network addresses, or ownership changes.
- Document which alarms notify people, which integrate with monitoring, and who is responsible for responding.
Troubleshooting notification failures
Email troubleshooting checklist
- Confirm that the SMTP server hostname is correct and resolvable from vCenter Server.
- Confirm that the sender account is populated and accepted by the mail relay.
- Check firewall rules, network routing, and SMTP relay permissions.
- Verify that the alarm has an email action and that recipient addresses are correct.
- Check spam, quarantine, and other mail-filtering systems.
SNMP troubleshooting checklist
- Confirm the receiver hostname or address and destination port.
- Verify that the receiver is listening for traps and allows traffic from vCenter Server.
- Check DNS, routing, and firewall rules.
- Confirm that the alarm includes an SNMP trap action.
- Verify that no more than four SNMP receivers are configured.
Practical combined configuration example
Suppose a critical datastore alarm must notify both people and an event-management platform. First, configure the vCenter Server SMTP server and sender identity. Next, add the event-management server as an SNMP receiver. In the alarm’s Actions page, add an email action for the on-call distribution list and an SNMP trap action for the configured receiver. Associate both actions with the critical alarm state, save the alarm, and trigger a controlled test.
The test is complete only after the mailbox receives the expected message and the monitoring platform records the corresponding trap with enough context to identify the affected datastore and alarm.
Exam-relevant notes
- SMTP and SNMP receiver settings are delivery infrastructure; an alarm action is still required.
- Email actions use the configured SMTP server and sender identity.
- SNMP trap actions use configured SNMP receiver destinations.
- Up to four SNMP receivers can be configured.
- Alarm actions must be associated with the relevant state or trigger condition.
- Testing should validate the full path from condition, to action, to endpoint, to human or monitoring-system processing.
For a concise reference to this topic, see Notifications Explained.