VMware ESXi and vSphere Cluster Management
VMware vSphere Alarm Actions Explained
Learn how vSphere alarm actions work, which objects support them, how state transitions and repeat settings control execution, and how to design safe automation.
A vSphere alarm is a vCenter-managed rule that monitors an inventory object or condition and changes state when configured criteria are met. An alarm action is the notification or operation performed when that alarm reaches or changes to a configured state.
Detection and response are separate decisions. The alarm definition detects a condition, such as datastore capacity crossing a threshold. Its action configuration determines what happens next, such as sending an email, sending an SNMP trap, or running a script. Actions are associated with state transitions—changes from one alarm state to another—not simply with a static state that remains unchanged.
What an Alarm Definition Contains
An alarm definition normally combines the monitored object, trigger or condition, thresholds where applicable, alarm states, and actions. In the vSphere Client, create or edit the definition for the intended inventory object, configure its condition, and then configure responses for each supported transition.
- Create or edit an alarm definition for the intended inventory object type.
- Define the trigger, condition, and associated thresholds where applicable.
- Open the action configuration area.
- For each supported transition, select an action or leave it with no action.
- Choose whether each action runs once or repeats.
- Configure email recipients, SNMP destinations, or command and script details.
- Test the behavior safely before applying it to production workloads.
Review alarms in vSphere and alarm trigger types for the condition side of alarm configuration.
Objects That Can Be Monitored
Alarm definitions can monitor these vCenter inventory object types:
| Monitored object type | Purpose or example condition | Common action support | Additional object-specific actions |
|---|---|---|---|
| Virtual machines | Guest availability, power, or resource condition | Email, SNMP trap, command or script where supported | Power on, power off, suspend, reset, migrate |
| Hosts | Hardware health, connectivity, capacity, or host state | Email, SNMP trap, command or script where supported | Maintenance mode, standby, reboot, shutdown |
| Clusters | Cluster capacity, health, or configuration | Email, SNMP trap, command or script where supported | None listed here |
| Datacenters | Aggregated inventory or availability condition | Email, SNMP trap, command or script where supported | None listed here |
| Datastores | Capacity, accessibility, or performance condition | Email, SNMP trap, command or script where supported | None listed here |
| Distributed switches | Networking health or configuration condition | Email, SNMP trap, command or script where supported | None listed here |
| Distributed port groups | Port-group networking or configuration condition | Email, SNMP trap, command or script where supported | None listed here |
| Datastore clusters | Storage-cluster capacity or placement condition | Email, SNMP trap, command or script where supported | None listed here |
| vCenter Server | vCenter health or service condition | Email, SNMP trap, command or script where supported | None listed here |
Exact action availability depends on the object type, alarm definition, and vSphere version. Select only actions presented as supported for the definition being edited.
Actions Available Across Alarm Types
Where supported by the alarm configuration, the following general-purpose actions can be selected for all listed alarm object types:
- Email notification: sends a message to configured recipients.
- SNMP trap notification: sends a Simple Network Management Protocol notification to a monitoring or management platform.
- Run a command or script: starts an approved external operation for diagnostics or controlled remediation.
| Action | Available for all listed alarm types | Host-specific | VM-specific | Operational impact |
|---|---|---|---|---|
| Email notification | Yes, where supported by the definition | No | No | Provides visibility without changing workload state |
| SNMP trap notification | Yes, where supported by the definition | No | No | Forwards an event to external monitoring |
| Run command | Yes, where supported by the definition | No | No | Impact depends on the script and its permissions |
| Enter or exit maintenance mode | No | Yes | No | Can evacuate or stop workloads on a host |
| Enter or exit standby mode | No | Yes | No | Changes host power availability |
| Reboot or shut down host | No | Yes | No | Potentially disruptive to multiple workloads |
| Power on, power off, suspend, reset, or migrate VM | No | No | Yes | Changes VM availability, execution, or placement |
Host-Specific Actions
Host alarms can support actions that change the operating state of an ESXi host:
- Enter maintenance mode: places the host into a state used for maintenance, normally requiring workloads to be evacuated or stopped according to the environment's capabilities and policies.
- Exit maintenance mode: returns the host to normal service eligibility.
- Enter standby mode: places the host into a reduced-power state.
- Exit standby mode: returns the host from standby to service.
- Reboot the host: restarts ESXi.
- Shut down the host: powers off the host.
These are potentially disruptive remediation actions. Before automating them, validate workload evacuation, cluster capacity, admission-control behavior, maintenance procedures, dependencies, and change-control requirements. See admission control and host inventory management for related administration concepts.
Virtual-Machine-Specific Actions
VM alarms can support the following VM operations:
- Power on: starts a VM that is powered off. Recovery automation must account for the cause of the shutdown, application startup order, and dependent services.
- Power off: stops a VM. Treat this as a disruptive operation because guest applications may not shut down cleanly.
- Suspend: pauses VM execution and preserves its suspended state. It can affect time-sensitive applications and resource availability.
- Reset: restarts the guest abruptly, similar to pressing a physical reset button. Use only when the expected benefit outweighs possible data loss.
- Migrate: changes the VM's host or placement. Validate destination capacity, network and storage access, licensing, affinity rules, and application constraints. See admission-control policy for related placement planning.
Alarm States and Visual Indicators
vSphere alarm actions use three primary states:
- Normal: the healthy or cleared state, shown as a green circle.
- Warning: an intermediate state requiring attention, shown as a yellow triangle.
- Critical: a serious state requiring prompt attention, shown as a red diamond.
These indicators appear in the alarm action configuration interface and help identify the source and destination of each transition.
State Transitions That Invoke Actions
A transition is a change between states. Common configurable paths include Normal to Warning, Warning to Critical, Critical to Warning, and Warning to Normal. An action assigned to one path does not automatically run for every other path.
| Transition | Typical operational meaning | Possible action choice | Execution modes |
|---|---|---|---|
| Normal to Warning | A condition crossed an attention threshold | Send one capacity or health email | No action, Once, or Repeat |
| Warning to Critical | The condition worsened significantly | Send an SNMP trap and run an approved diagnostic script | No action, Once, or Repeat |
| Critical to Warning | The condition improved but is not clear | Send an update or continue controlled reminders | No action, Once, or Repeat |
| Warning to Normal | The condition cleared | Send one recovery notification | No action, Once, or Repeat |
Action Execution Frequency
| Setting | Behavior | When it stops | Recommended use |
|---|---|---|---|
| No action | No response is executed for that transition | There is no action to stop | Use when the transition is informational or intentionally ignored |
| Once | Executes the selected action one time when the transition occurs | After that execution | Use for a single notification or controlled one-time operation |
| Repeat | Executes repeatedly at the configured interval while the alarm remains in the resulting state | When another state transition occurs | Use for reminders or safe, idempotent diagnostics |
The historical default repeat interval was five minutes. Verify the configured interval in the vSphere version and alarm interface you operate rather than assuming that value applies unchanged.
Practical Configuration Examples
Datastore Capacity Warning
For a datastore alarm, assign an email action to the Normal-to-Warning transition and set it to Once. This gives the storage or virtualization team an early notification while leaving time to investigate before service is affected.
Escalating Host Hardware Condition
For a host alarm, assign an SNMP trap and an approved diagnostic script to the Warning-to-Critical transition. This combines monitoring visibility with controlled data collection instead of immediately rebooting the host.
VM Availability Response
For an applicable VM alarm, a policy may permit a power-on action after a configured transition. Validate application dependencies, startup order, and the reason the VM became powered off before enabling this automation.
Critical Condition Reminders
A repeated email or SNMP action can remind operators about an unresolved Critical condition. Tune the interval carefully so reminders improve visibility without creating an alert storm.
Condition Recovery
Assign a single email action to Warning-to-Normal to announce recovery. A recovery message closes the operational loop and distinguishes a cleared condition from an ongoing incident.
Host Maintenance Automation
A host-specific maintenance-mode action should be considered only after confirming workload evacuation behavior, cluster capacity, and approved maintenance procedures. A single host action can affect many VMs.
Safe Alarm-Action Design
- Start with notification-only actions. Add automated remediation after the condition, script, and recovery path have been validated.
- Do not automatically reboot or shut down hosts, or power off, reset, or migrate workloads, without checking dependencies and business impact.
- Use appropriate repeat behavior to prevent alert storms and duplicate script execution.
- Test alarm definitions and command actions in a non-production environment.
- Use externally maintained, approved scripts rather than embedding unreviewed logic in an alarm workflow.
- Make scripts idempotent when Repeat is enabled, meaning repeated execution produces no harmful additional effect.
- Log script activity, return meaningful exit status information, protect credentials, and limit automation permissions.
Troubleshooting Alarm Actions
No Email or SNMP Message
- Confirm that an action is assigned to the exact transition that occurred.
- Verify email or SNMP infrastructure, destinations, reachability, recipient addresses, and monitoring-platform trap handling.
- Check whether the action was set to Once and already executed.
Too Many Repeated Notifications or Scripts
- Check whether Repeat was selected instead of Once.
- Review the configured repeat interval; five minutes was a historical default, but the current value must be verified.
- Confirm that the alarm has remained in the same Warning or Critical state.
- Use deduplication, escalation policies, or a less frequent interval where supported.
Command Action Does Not Correct the Condition
- Verify the script path, permissions, execution context, dependencies, and logs.
- Test the script independently with safe inputs.
- Confirm that it is attached to the intended transition.
- Ensure that repeated execution cannot produce harmful side effects.
Unexpected Host or VM Impact
- Review whether the selected action is disruptive, such as host reboot, host shutdown, VM power-off, VM reset, or migration.
- Validate cluster capacity, workload dependencies, admission control, and evacuation requirements.
- Restrict automation to conditions with a well-understood remediation path.
- Return to notification-only behavior until the workflow is tested.
No Recovery Notification
- Confirm that an action is configured for Warning-to-Normal.
- Verify that the alarm actually returned to Normal instead of remaining in Warning or Critical.
- Check action frequency and notification delivery settings.
Exam-Relevant Notes
- An alarm condition detects a problem; an alarm action defines the response.
- Actions are attached to state transitions, not merely to a persistent state.
- Email, SNMP traps, and command or script actions are the general response categories where supported.
- Maintenance, standby, reboot, and shutdown are host-specific operations.
- Power, suspend, reset, and migration operations are VM-specific.
- Once runs once for a transition; Repeat continues until another transition occurs.
- Always verify the repeat interval in the installed vSphere version.