Vmware Esxi

Alarms in vSphere

Learn how vSphere alarms monitor VMs, ESXi hosts, datastores, and networks through vCenter Server, including triggers, severity levels, actions, configuration, and troubleshooting.

A vSphere alarm is a vCenter Server monitoring definition that evaluates events, object states, or metric thresholds. When a defined condition occurs, the alarm can change status and perform one or more actions, such as sending an email, forwarding an SNMP trap, or running a command.

Alarms help administrators detect capacity, performance, availability, and configuration problems before they become service-impacting incidents. They also separate two concepts that are often confused:

• Alarm condition: The event, state, or measured value that is being evaluated.
• Alarm action: What vCenter Server does after the condition changes the alarm status.

Why vSphere alarms matter

Without alarms, administrators may need to inspect performance charts, events, and object health manually. An alarm provides continuous evaluation and highlights conditions that require attention. Properly designed alarms support:

• Proactive monitoring: Detect capacity or performance degradation before an outage.
• Incident awareness: Notify the responsible team when a host, VM, datastore, or network object changes state.
• Faster remediation: Include enough context to identify the affected object and begin investigation.
• Operational consistency: Apply the same thresholds and response process across an inventory scope.

An alarm does not automatically identify the root cause. For example, a high CPU alarm identifies sustained CPU demand, but the cause might be an application workload, incorrect VM sizing, host contention, or a software fault.

vCenter Server is required

Alarm management is provided through vCenter Server, the centralized vSphere management platform. vCenter Server manages inventory objects and evaluates alarm definitions against those objects.

An administrator connected directly to an individual ESXi host cannot create and manage the equivalent vCenter alarms. The host can expose local health and performance information, but centralized alarm scope, inventory relationships, and alarm actions belong to vCenter Server.

Alarm scope follows the vCenter inventory. Depending on permissions and where an alarm is created, it can apply to one object, a group of objects, a cluster, a datacenter, or another supported inventory scope. For background, see adding an ESXi host to vCenter Server inventory and communication between vCenter Server and ESXi.

Objects that can have alarms

An inventory object is a managed vSphere entity, such as a virtual machine, host, datastore, or network object. The available triggers and metrics depend on the selected object type.

Use the object type to determine what makes a useful alarm. A datastore capacity threshold is meaningful for a datastore, while a VM power-state event is meaningful for a virtual machine. More detail is available in alarm trigger types.

Alarm trigger types

A trigger is the event, condition, state change, or metric threshold that causes an alarm to change status. Common trigger categories are condition- or metric-based, event-based, and state-based.

Condition- or metric-based triggers

These triggers evaluate a measurable value or detectable condition. Examples include CPU utilization above a percentage, datastore free space below a percentage, or a resource value that remains outside an acceptable range.

Metric alarms commonly use a duration requirement. A VM that briefly reaches high CPU usage may not need an alert, while sustained high usage may indicate a real performance problem.

Event-based triggers

An event-based alarm responds to an event reported by vCenter Server or a managed object. Examples include a host power-state change, a configuration change, or a storage accessibility event. The event itself is the trigger; the notification or script is the action.

State-based triggers

A state-based alarm evaluates whether an object is healthy, available, connected, or otherwise in an expected state. For example, an alarm may identify an unavailable host or an inaccessible datastore.

Transitions between states

A trigger can be configured so that an alarm moves between normal, warning, and alert states. A metric can first cross a warning threshold and later cross a critical threshold. When the value returns to the normal range, the alarm can reset according to its configuration.

Alarm severity and status levels

Severity helps prioritize administrative response. The exact threshold and action policy should reflect the service impact of the monitored object.

• Normal or green: The monitored object is within the expected state or range. No alarm response is normally required.
• Warning or yellow: An early warning threshold has been reached. The issue may not be critical yet, but investigation or planned remediation may be appropriate.
• Alert or red: A critical threshold or serious state has been reached. The responsible team should respond promptly.

A status change can initiate an action. For example, a datastore may remain green while it has sufficient free space, become yellow when capacity is constrained, and become red when free space reaches a critical level. After capacity is restored, the alarm can return to green. This is an alarm reset: the transition back to normal after the triggering condition is gone or after the configured reset process is completed.

Do not assume that acknowledging an alarm fixes the condition. Acknowledgement records that someone has seen it; recovery requires the underlying condition to return to normal. If a status remains active, verify the metric, state, evaluation interval, and reset configuration. See acknowledging an alarm for the distinction between acknowledgement and remediation.

Built-in vCenter alarms

vCenter Server includes predefined alarms for common infrastructure conditions. Examples include:

• An ESXi host power-state change or availability problem.
• A datastore approaching or exceeding a capacity threshold.
• High CPU usage on a virtual machine.

Review built-in alarms before creating custom definitions. A predefined alarm may already provide the required trigger and reduce duplicate notifications. Review its scope, thresholds, enabled state, and actions rather than assuming that its defaults match local policy.

Custom alarms

Create a custom alarm when a built-in alarm is too broad, uses unsuitable thresholds, or does not cover a local operational requirement. A useful custom alarm should answer three questions:

• What object or inventory scope is important?
• What condition indicates a meaningful risk?
• Who needs to know, and what safe response is justified?

General configuration workflow

1. Select the applicable vCenter inventory object or scope in the vSphere Client.
2. Review existing built-in alarms and inherited definitions.
3. Create or edit an alarm definition only when customization is required.
4. Select the trigger category and condition.
5. Set warning and alert thresholds, event criteria, and any duration requirements.
6. Configure one or more actions, such as email, SNMP trap, or command execution.
7. Enable the alarm and validate status transitions and notifications with a controlled test.

Alarm design checklist:
1. Object scope: VM, host, datastore, network object, or group
2. Trigger: metric, event, or state
3. Warning threshold: early intervention point
4. Alert threshold: critical intervention point
5. Duration: filter short-lived spikes when appropriate
6. Actions: notify first; automate only when safe
7. Reset behavior: define how recovery is recognized
8. Validation: test before relying on production alerts

Avoid thresholds that are so sensitive they respond to normal fluctuations. Also check for overlapping built-in and custom alarms. Excessive, repetitive, or low-value notifications create alert fatigue, which reduces responsiveness to important alerts.

Alarm actions

Actions run after a configured status transition or event. Choose actions according to the urgency, ownership, and safety of the response.

Email notifications

Email is suitable when a human team must investigate. Ensure that vCenter Server has valid outbound mail settings and that recipient addresses are correct. Test with a controlled condition and verify delivery, sender identity, message routing, and any mail filtering.

SNMP traps

An SNMP trap is a Simple Network Management Protocol notification sent to an external monitoring or management system. Validate the destination, network path, receiver availability, and monitoring rule that maps the trap to an incident.

Command actions

A command action invokes a command or script. It can collect diagnostics or perform remediation, but automation introduces risk. Use a tested script, least-privilege permissions, clear logging, input validation, timeout and failure handling, and safeguards against repeated execution. Avoid destructive or irreversible actions until the behavior is proven in a controlled environment.

Practical alarm examples

Datastore capacity warning

For a datastore, configure a warning threshold when free storage becomes constrained and an alert threshold when it reaches a critical level. Send email to the virtualization or storage team and an SNMP trap to the central monitoring platform.

During investigation, check VM growth, snapshots, ISO images, logs, orphaned files, and whether capacity should be reclaimed or expanded. Do not treat a capacity alert as proof that expansion is the only solution.

Virtual machine CPU utilization

Configure a VM alarm for CPU usage that remains above a selected threshold for a sustained period. Notify the VM owner or operations team, then determine whether demand is legitimate, temporary, or caused by an application problem.

Review VM sizing and host contention before changing resource allocation. Increasing virtual CPU does not automatically solve an application or scheduling problem.

ESXi host power-state event

Use a high-priority host alarm for a power-state change or an unavailable host. First determine whether the event is planned maintenance. If it is unexpected, check host connectivity, hardware, management network access, and the availability of affected virtual machines.

Local operational policy

A custom alarm may be appropriate for a selected VM, host, or datastore group when a local threshold or event is not adequately covered by a generic alarm. Set warning and alert levels according to business impact, assign only necessary actions, test in a controlled environment, and tune the policy using observed behavior.

Monitoring and response workflow

1. Receive the notification: Identify whether it arrived by email, SNMP, or another configured channel.
2. Identify the object: Record the VM, host, datastore, network object, and inventory scope.
3. Read the condition: Determine the trigger, current status, threshold, event, and time of transition.
4. Verify the condition: Compare the alarm with current performance data, object health, and recent vCenter events.
5. Investigate the root cause: Check dependencies, recent changes, capacity, contention, connectivity, and planned maintenance.
6. Remediate: Apply a safe corrective action or escalate to the responsible team.
7. Confirm recovery: Verify that the metric or state returns to normal and that the alarm resets as expected.
8. Review the alarm: If it was noisy or incomplete, adjust thresholds, duration, scope, or actions without hiding a real problem.

vCenter Server log levels and alarm investigation

vCenter Server logs provide context when an alarm, event, notification, or command action does not behave as expected. They can help correlate an alarm transition with object events, service activity, notification attempts, and errors.

Common logging concepts include:

• Informational: Normal operational messages and significant state changes.
• Warning: Conditions that may affect operation but are not necessarily failures.
• Error: Failures or conditions that require investigation.
• Diagnostic or verbose: Detailed troubleshooting information, often useful for tracing a complex issue.

Increasing logging detail can help troubleshoot an alarm, but it also increases log volume and storage or analysis overhead. Use verbose logging deliberately, for a defined troubleshooting period when possible, and return to an appropriate operational level afterward. Also review relevant vCenter events and service logs rather than relying on the alarm message alone.

Troubleshooting vSphere alarms

An expected alarm does not trigger

• Confirm that the alarm is enabled and attached to the intended inventory scope.
• Verify that the object is managed by vCenter Server rather than accessed only through a direct ESXi connection.
• Check that the trigger type, metric, event, and thresholds match the actual condition.
• Confirm that the condition persisted long enough when time-based evaluation is configured.
• Review relevant vCenter events and logs.

The alarm triggers too frequently

• Review warning and alert thresholds for unrealistic sensitivity.
• Use a duration requirement when short resource spikes are not actionable.
• Check for overlapping built-in and custom alarms.
• Adjust the policy only after confirming that recurring alerts do not indicate a genuine capacity or performance problem.

The alarm is active but no notification arrives

• Verify email recipients and vCenter outbound mail settings.
• Confirm the SNMP destination, network path, and receiver availability.
• Check firewall, routing, DNS, and service connectivity relevant to delivery.
• Review the action configuration and associated vCenter logs.

A command action does not remediate the condition

• Verify the command path, script syntax, execution permissions, and required environment.
• Review script output and error logs.
• Confirm that the action matches the condition and does not depend on unavailable services.
• Use notification-only behavior while testing automation.

The alarm remains warning or alert after remediation

• Confirm that the monitored metric or state has actually returned to the normal range.
• Allow for the monitoring evaluation interval.
• Review reset behavior and whether acknowledgement or manual reset is part of the process.
• Check for a continuing underlying event or condition.

Exam-relevant notes

• vSphere alarm management is a vCenter Server function, not an equivalent feature available from a direct ESXi-only connection.
• The inventory object determines which conditions and metrics are available.
• A trigger defines when an alarm changes status; an action defines what happens afterward.
• Green means normal, yellow means warning, and red means alert or critical.
• Built-in alarms should be reviewed before creating custom alarms.
• Email, SNMP traps, and command or script execution are different response mechanisms with different operational risks.
• An acknowledged alarm is not necessarily a recovered alarm; verify the underlying condition and reset behavior.

For related administration concepts, review assigning permissions, the VMware ESXi online course, and VMware ESXi administration topics.