VMware ESXi and vSphere Cluster Management
Create Virtual Machine Alarms in vCenter Server
Learn how to create a vCenter Server virtual machine alarm with CPU warning and critical thresholds, duration settings, and email notifications.
A vCenter Server alarm is a monitoring definition that changes status and can run actions when configured conditions, states, or events occur for an inventory object. This lesson shows how to create a condition-based alarm for a virtual machine (VM), using CPU usage thresholds and email notifications.
What vCenter Server alarms do
Alarms notify administrators when a monitored object experiences a defined event, condition, or state change. An inventory object is an item managed by vCenter Server, such as a virtual machine, ESXi host, network, or datastore.
An alarm definition is attached to an inventory object. Its conditions are evaluated in the context of that object. For example, a VM CPU alarm evaluates the CPU usage of the selected VM, while a datastore alarm evaluates properties of the selected datastore.
- Virtual machines: Monitor CPU usage, memory-related conditions, power state, and other VM properties.
- ESXi hosts: Monitor host health, resource usage, and state changes.
- Networks: Monitor network-related conditions and events.
- Datastores: Monitor capacity, accessibility, and storage conditions.
This lesson uses a condition or state alarm. It evaluates a monitored property or status against configured criteria. An event-based alarm instead responds to a specific event, such as a recorded operation or change in the environment.
Prerequisites
- Access to vCenter Server through the vSphere Web Client, the vSphere management interface used to configure inventory objects.
- Sufficient vCenter Server privileges to create and modify alarm definitions on the selected VM.
- A target virtual machine that you want to monitor.
- Configured email or other notification infrastructure if the alarm will send email. The alarm action alone does not guarantee mail delivery unless the environment's mail settings and delivery path work correctly.
Open alarm definitions for a virtual machine
- Sign in to the vSphere Web Client and open the vCenter inventory.
- Select the target virtual machine.
- Open Manage.
- Open Alarm Definitions.
- Use Add to start a new alarm definition.
The exact placement of labels can vary between vSphere versions, but the workflow remains centered on the selected VM's management area and alarm definitions.
Create the alarm definition
1. Name the alarm
Give the alarm a name that identifies both the resource and its purpose. For example:
VM CPU Warning and Critical - Application VM 01A descriptive name helps administrators understand the alarm when it appears in lists, notifications, and operational reports.
2. Select the alarm type
Choose the option that monitors specific conditions or state. This scopes the example to a VM condition alarm. The definition will evaluate the selected VM's CPU usage and change status when the configured thresholds are met.
Configure CPU trigger conditions
A trigger condition is the measurable property, state, or threshold that causes an alarm to change status. Add a condition for VM CPU usage.
Configure separate severity levels:
- Warning: A lower-severity threshold indicating that attention may be needed.
- Critical: A higher-severity threshold indicating a more urgent problem.
Set the critical threshold higher than the warning threshold. Also configure a duration, which is the time the condition must remain true before the alarm triggers. A rule such as “CPU usage greater than 20 percent for 30 seconds” means that a brief spike is ignored; the metric must remain above the threshold for the full duration.
| Alarm state | Metric | Comparison | Threshold | Required duration | Result |
|---|---|---|---|---|---|
| Warning | VM CPU usage | Greater than | 20 percent | 30 seconds | Warning status |
| Critical | VM CPU usage | Greater than | 30 percent | 30 seconds | Critical status |
With this example, the VM enters Warning status when CPU usage exceeds 20 percent continuously for 30 seconds. It enters Critical status when CPU usage exceeds 30 percent continuously for 30 seconds.
These values demonstrate the configuration only. Select thresholds that match the workload, normal operating range, capacity plan, and response procedures. Do not retain demonstration values blindly.
Configure alarm actions
An alarm action is an automated response performed when an alarm enters or remains in a configured state. Actions can be configured independently for Warning and Critical states.
Warning email action
- Add an email notification action for the Warning state.
- Specify the intended recipient, such as the administrator or an operations mailbox.
- Configure the action to send once when the warning condition is met.
Critical email action
- Add an email notification action for the Critical state.
- Specify the intended recipient.
- Configure an initial email when Critical begins.
- Set a repeat notification interval, such as every 5 minutes, while the Critical condition remains active.
A repeat notification interval is the period between recurring notifications while an alarm condition remains active.
| Alarm state | Action | Recipient | Initial notification | Repeat behavior | Stop condition |
|---|---|---|---|---|---|
| Warning | Send email | Administrator | Once when Warning begins | No repeat | Alarm recovery or state change |
| Critical | Send email | Administrator | When Critical begins | Every 5 minutes | Manual reset or metric recovery |
Recurring Critical messages continue according to the configured interval until the alarm recovers or is reset. Ensure that the recipient and repeat frequency are appropriate for the operational impact; a short interval can create unnecessary message volume.
Understand alarm states, acknowledgement, and reset
| State | Meaning | Typical administrator response | Notification behavior |
|---|---|---|---|
| Green/normal | The monitored condition is not active. | No action required. | No active alarm notification. |
| Yellow/warning | The lower-severity threshold is met. | Investigate workload and resource demand. | Warning action runs as configured. |
| Red/critical | The higher-severity threshold is met. | Investigate urgently and remediate. | Critical action repeats as configured. |
| Acknowledged | An administrator has marked the alarm as seen. | Continue remediation as needed. | Acknowledgement does not resolve the condition. |
Normally, the alarm starts in Green. When a trigger condition is met for its required duration, it transitions to Warning or Critical. If CPU usage later falls below the applicable condition and the alarm's recovery criteria are met, it can return to Green automatically.
To acknowledge an alarm means to record that an administrator has seen it. Acknowledgement is an administrative workflow step, not a repair. It does not reduce CPU usage, terminate a problematic process, add capacity, or resolve the monitored condition.
Reset to green means returning an alarm to its normal state manually or after configured recovery criteria are met. A manual reset should be used only when appropriate, because the alarm may become active again if the CPU condition remains true.
Review and save the completed alarm
Before saving, review each part of the alarm definition:
- The selected virtual machine is the intended object.
- The alarm name identifies the monitored resource and purpose.
- The alarm type monitors specific conditions or state.
- The condition measures VM CPU usage.
- Warning and Critical comparisons, thresholds, and durations are correct.
- The Critical threshold is more severe than the Warning threshold.
- Warning and Critical email actions are assigned to the intended states.
- The recipient address is correct.
- Warning sends once, while Critical sends initially and repeats at the selected interval.
Save the definition, then verify that it appears in the VM's Alarm Definitions list. Confirm that the definition is enabled and attached to the intended VM.
Validate alarm behavior
After saving, check the VM's alarm status and notification delivery when a testable condition occurs. Confirm that:
- The status changes from Green to Warning when CPU usage exceeds the Warning threshold for the configured duration.
- The status changes to Critical when CPU usage exceeds the Critical threshold for its configured duration.
- The Warning email is delivered once.
- The Critical email is delivered initially and repeats at the configured interval while the condition remains active.
- Notifications stop after CPU usage recovers or the alarm is reset appropriately.
- The alarm returns to Green when its recovery criteria are met.
Use current and historical VM performance data when validating the condition. A high instantaneous value may not be sufficient if it does not remain above the threshold for the full duration.
Troubleshooting
The option to create or edit an alarm is unavailable
- Confirm that the selected object is the intended virtual machine.
- Open the VM's Manage area and Alarm Definitions section.
- Review assigned vCenter permissions and the required alarm-management privileges.
The alarm does not trigger despite high CPU activity
- Check whether CPU usage exceeded the configured threshold continuously for the complete duration.
- Verify the selected metric, comparison operator, Warning threshold, Critical threshold, and duration.
- Compare the alarm's metric with current and historical VM performance data.
- Confirm that the alarm is enabled and attached to the intended VM.
Email notifications are not received
- Verify the recipient address configured in each alarm action.
- Confirm that vCenter Server email or SMTP notification settings are configured.
- Check the mail delivery path and any filtering or mailbox rules.
- Review whether actions are assigned to the expected Warning and Critical states.
- Check alarm status and event history to confirm that the alarm actually entered the state that sends the action.
Critical emails continue after investigation
- Check whether CPU usage remains above the Critical threshold.
- Confirm the configured repeat notification interval.
- Remediate the source of CPU demand, allow the metric to recover, or reset the alarm to Green when appropriate.
Acknowledging the alarm does not stop the issue
Acknowledgement only records that an administrator has seen the alarm. Investigate guest processes, workload demand, available capacity, and VM resource allocation. Then confirm that the metric recovers and that the alarm returns to Green.
Key points
- Alarm definitions are attached to inventory objects and evaluate conditions relevant to those objects.
- A VM condition alarm can use CPU usage, severity thresholds, and a duration to avoid reacting to brief spikes.
- Warning and Critical actions are independent and can use different notification behavior.
- Acknowledging an alarm does not resolve the monitored condition.
- Critical notifications can repeat until recovery or manual reset, depending on the action configuration.
- Always validate thresholds against the workload instead of copying example values without review.