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:
1 | Get-EventType | Where-Object {$_.Description -like "*reconfig*"} |
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:
1 2 3 4 5 6 | $alarmTriggerInput = @{ EventType = $vmReconfigEvt EntityStatus = "Yellow" EntityType = "VirtualMachine" } $alarmTrigger = New-AlarmTrigger @alarmTriggerInput |
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | $vmReconfigEvt = Get-EventType | Where-Object {$_.Description -eq "VM reconfigured"} $alarmTriggerInput = @{ EventType = $vmReconfigEvt EntityStatus = "Yellow" EntityType = "VirtualMachine" } $alarmTrigger = New-AlarmTrigger @alarmTriggerInput $alarmDefInput = @{ Name = "VM Reconfiguration" Description = "Alarm to monitor virtual machine reconfiguration events" AlarmTrigger = $alarmTrigger Entity = Get-Folder -Type Datacenter -NoRecursion } New-AlarmDefinition @alarmDefInput |
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!
This is looking great, but the first Alarm that I wanted to script the creation of has a trigger that does not appear in Get-EventType
Following the article here:
https://www.virtuallyghetto.com/2013/01/detecting-duplicate-ip-address-for-your.html
we need to create an alarm with a trigger of “esx.problem.net.vmknic.ip.duplicate” which we can copy and paste into the HTML5 interface as a trigger and after saving the alarm it changes to become “A duplicate IP address was detected on a vmknic interface”
Using Get-EventType to search for this as the description does not return any results, but if I Get-AlarmTrigger from a manually created trigger, it has the proper EventType data.
Get-EventType does have “Duplicate IP detected”, but this does not trigger for a duplicate IP on vmknic across hosts as we had encountered.
Is there any way to manually create the proper EventType object to feed into New-AlarmTrigger so we can script this across multiple vCenter?
Did you figure out how to create a alarm where the trigger does not appear in Get-EventType?
It’s very informative article. Thank you for sharing with us.
Definitely trying this for my next vmware project!
Very Helpful. Thanks for sharing. Keep it Up : )
wow amazing and helpful information
wow this useful information
Its Very Fantastic Post..Thanku For Giving such Valuable Information
useful information great articles sir
Great, it’s very informative article. Thank you for sharing.
It’s very informative article. Thank you for sharing with us.