Acknowledging a vCenter alarm records ownership and stops its alarm actions; it does not clear the alarm. A red or yellow state after acknowledgement can therefore be expected. For an event-triggered alarm, the state can also remain after the incident ends if vCenter never receives the corresponding normal-condition event. Resetting its colour is a different operation from repairing the cause.
These distinctions come from the vSphere 8.0 acknowledgement and event-reset guides linked below. This article is source-researched only. No alarm, rule or cluster configuration was changed, and its example is hypothetical.
Separate the incident, the state and the action
An alarm tells an operator about a condition or event. The alarm's current state, its acknowledgement and the actions it produces must be read separately. The acknowledgement guide explicitly says that actions are discontinued when an alarm is acknowledged, while the alarm is not cleared or reset.
That matters when an operator says, “The emails stopped, so the problem must be fixed.” The stopped emails can be explained by acknowledgement alone. The same guide describes acknowledgement as telling colleagues that someone owns the issue. Ownership is useful operational information, but it is not component-health evidence.
An event alarm has another boundary. The event-reset guide explains that it might not return to normal if vCenter does not retrieve the event identifying the normal condition. That is a specific event-driven state problem. Do not generalise it to every current CPU, capacity or availability warning.
This diagnosis is UI-only. No exact-release PowerCLI or API listing procedure is claimed here.
Read the alarm in context
Use existing authorised vSphere Client access. Record the vCenter build, object identity, alarm name, trigger time and the incident interval. Read the object's Monitor → Issues and Alarms → Triggered Alarms view and the relevant definition or linked event where available. The important distinction is what the alarm evaluates, not merely which colour it currently displays.
Inspect whether the alarm is acknowledged. Keep that observation separate from whether the underlying condition is currently present. Use the component's existing health evidence and incident records to establish the latter. For an event alarm, look for the event that should have represented recovery and whether it is available in the retained history.
These are read-only observations. The Acknowledge and Reset to Green controls change alarm state or behaviour and should not be clicked just to see what happens. The documentation gives separate privileges: Alarm.Alarm Acknowledge for acknowledgement, and Alarm.Set Alarm Status for reset. A disabled control is not enough to identify the cause; confirm the alarm case and the account's applicable permissions without broadening access.
Worked example: stopped notifications, unresolved condition
Imagine an alarm that notified the operations team when a host CPU condition triggered. An administrator acknowledges it at 09:10. Notifications stop, but the alarm remains red and the existing performance evidence still shows the condition.
The observations agree with the documented behaviour. There is no reason to rebuild the alarm merely because acknowledgement did not turn it green. The team still needs to address the CPU incident, using a separate performance diagnosis.
Now consider an event-triggered alarm whose component has recovered according to independent health evidence. The normal-condition event is absent, and the alarm remains triggered. That is the type of situation in which the event-reset guide describes a manual reset. A reviewed reset would reconcile the alarm presentation with established recovery; it would not cause the recovery itself. Preserve the trigger and recovery evidence before considering that administrative action.
When ordinary reset guidance does not apply
Broadcom KB 396899 documents a particular HA failover banner in vCenter 7.x/8.x for which acknowledgement and reset are unavailable. Its workaround changes HA configuration. This is an exception to generic alarm handling, not a reason to cycle HA whenever an alarm persists.
If the exact banner and disabled controls match, record the KB match and escalate the protection-impact decision to the cluster owner. Disabling and re-enabling HA is outside this diagnostic and has not been validated here. Do not substitute a cluster-wide protection change for establishing the actual alarm type.
Acceptance and reversal
A useful diagnosis identifies the object, trigger, acknowledgement, current underlying condition and any missing recovery event. If the condition remains unresolved, retain that conclusion even if a cosmetic reset is possible. If a later approved reset is performed, acceptance still depends on the independent component evidence and absence of a legitimate new trigger.
Read-only inspection requires no rollback. A reset cannot recreate the original incident or recover discarded event history, and restoring a colour is not a recovery plan. Notification behaviour after a management action needs its own authorised verification; none was performed here.
Learning notes
- Acknowledgement assigns ownership and stops actions without clearing state.
- Event alarms can depend on a separate normal-condition event.
- Green presentation and a repaired component are different evidence.
References
- A02-D1: Acknowledge Triggered Alarms
- A02-D2: Reset Triggered Event Alarms
- A02-S1: "vSphere HA initiated a failover action on 1 virtual machine in the cluster xxxxx in datacenter xxxx" alarm cannot be removed