What’s New for vSphere Alarm Management

One of the hot topics at VMworld EU was around alarm management and the new cmdlets which were recently made available. There has been a solid set of alarm-based cmdlets that already exist and have been part of PowerCLI for many years. However, as evidenced by a PowerCLI session at VMworld in 2017 where we dug into some examples only available by the API, those cmdlets didn’t give quite give us everything we needed. Therefore, PowerCLI 11.5 added 6 new cmdlets and 3 updated cmdlets to help manage alarm definitions, create alarm triggers, and pull information about available event types and metrics.

These new cmdlets are as follows:

• New-AlarmDefinition
• Remove-AlarmDefinition
• New-AlarmTrigger
• Get-AlarmTrigger
• Get-EventType
• Get-Metric

The updated cmdlets are as follows:

• New-AlarmAction
• New-AlarmActionTrigger
• Set-AlarmDefinition

Let’s run through creating a new alarm with these cmdlets.

VM Reconfiguration Alarm Creation

There’s been a migration over the years to treat VM workloads in a more disposable fashion. This means that instead of making changes or updates directly to the deployed VM, we would destroy and re-deploy a new VM with the new configuration. Therefore, we’re looking to create an alarm when any VM has been reconfigured.

To create this alarm, we will need to make use of a couple of the new cmdlets that were introduced with PowerCLI 11.5. Namely: Get-EventType, New-AlarmTrigger, and New-AlarmDefintion

First, we need to find the particular event type related to a VM reconfiguration event. There are over 400 different event types, so we’ll want to get a little more specific by using a filter.

Filter Example:

Looking through the response, we can see the last event type is the one we happen to be looking to use.

Next, we need to create an alarm trigger which will be based off of the event type we found in the prior step. For this we will use New-AlarmTrigger. This new cmdlet will have two other parameters we will need to populate as well, EntityStatus and EntityType. The EntityStatus parameter controls what the alarm severity will be. The available statuses are listed here: EntityStatus values Example: an EntityStatus of “yellow” is a warning. The EntityType parameter controls what object types the alarm can be referenced against. Example: VirtualMachine, HostSystem

For our use case, we’re going to use the following code to create a warning when a VM reconfigure task has been performed:

Lastly, we will be defining our alarm with the New-AlarmDefinition cmdlet. There are a few parameters which we’ll use to define this new alarm, including: Name, Description, AlarmTrigger, and Entity. The first two are describing our new alarm. The AlarmTrigger parameter is referencing the trigger we built in the prior step. The Entity parameter is not quite as straightforward. This parameter is actually describing at what level the alarm should be applied. Example: to apply this alarm to only a specific cluster, the entity would be for that cluster object. For this use case, we want the alarm to apply across the entire vSphere environment so we will apply it to the top-level folder named “Datacenters”.

The code to create this new alarm will look like the following:

If we switch over to the vSphere Client, we can also see our newly created alarm there:

That’s it! Our new alarm is created and enabled by default for usage in our environment.

Listing Active Alarms

The next question is normally “how do we list the alarms with PowerCLI?” Unfortunately, there is not a function to list these alarms easily. However, almost every top-level, managed object (technically, ManagedEntity) has a property available at the vSphere API level that we can reference to easily discover any active alarms. This property is known as the TriggeredAlarmState. When it comes to PowerCLI, this property is available through an object’s ExtensionData.

Going back to our vSphere environment, we can modify a VM in PowerCLI and see that our newly created alarm does work as planned by referencing that TriggeredAlarmState property:

Then, in the vSphere Client, we will also see the following:

The output from the TriggeredAlarmState property feels like it’s being pulled directly from the vSphere API and doesn’t easily give us some important information which we can easily turn into a report. I created a new advanced function and shared it on the VMware Code Sample Exchange and on the PowerCLI Community repo, it’s called Get-TriggeredAlarm.

Get-TriggeredAlarm in action:

The code for Get-TriggeredAlarm:

Summary

The latest version of PowerCLI 11.5 gave us a number of updates, including a handful of new and updated cmdlets which allows us to streamline the process of automating vSphere alarm management. These 6 new cmdlets and 3 updated cmdlets help manage alarm definitions, create alarm triggers, and pull information about available event types and metrics. This blog took a look at how to easily create a new alarm, including identifying a particular event and creating an alarm trigger, as well as how to report back alarms that are already active for particular vSphere objects.

Install PowerCLI 11.5 today and let us know in the comments what you’d like to see added next when it comes to vSphere alarm management!