Home > Blogs > VMware PowerCLI Blog > Tag Archives: vCenter

Tag Archives: vCenter

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:

Example: Viewing a filtered list of Event types

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:

Example: Creating a new alarm based on VM reconfiguration events

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

Example: Newly created alarm as viewed in the vSphere Client

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:
Example: Modifying a VM and viewing the TriggeredAlarmState property

Then, in the vSphere Client, we will also see the following:
Example: Alarm as viewed in the vSphere Client

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:
Example: Get-TriggeredAlarm usage

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!

Automating File-Based Backups of vCenter Server Appliance

Did you know the vCenter Server Appliance (VCSA) has file-based backup options?

This ability was actually released in vSphere 6.5. However, there was one feature in particular that was missing: a scheduler. I’m happy to say that as part of vSphere 6.7, the VCSA received a backup scheduler!

Recently, my teammate, Emad Younis released a couple cool walkthroughs to the vSphere Central site to manage file-based backup and restore actions. Under the covers, both of these actions are served up by vSphere’s RESTful APIs and therefore PowerCLI can also be used to automate these actions! One other benefit of using the API, you don’t have to hand out the root credentials. Users with the ‘SystemConfiguration.Administrators’ permission are able to perform all of the following tasks through the API and PowerCLI!

To perform a file-based backup with PowerCLI, we’ll need to make use of the CIS module. Since the CIS module is a low-level module, let’s see a couple examples of this in action.

Create a File-Based Backup

Let’s first start with the process to perform a backup.

First step, log in to the CIS Service for the VCSA:

Next, we need to find the appropriate service to perform a backup:

File-Based Backup Example: Listing CIS Services

Based on the output, we will want the ‘com.vmware.appliance.recovery.backup.job’ service. We will store that into a variable so we can easily interact with that specific service. To see the method we are going to use, take that variable and pipe it to ‘Get-Member’.

File-Based Backup Example - Working with the CIS Service

As part of the respose, we’ll see two important items. First, the ‘create’ method which we’ll use to actually create the backup job. Second, the ‘Help’ property. We can use ‘Help’ to help us form the input for the backup job with the following command:

We can now fill in each of the parameters with information for our environment. There are a couple caveats here. First, the ‘parts’ parameter is expecting an input of an array type. Second, each of the password parameters require a special type in order to be accepted.

Finally, having input all of our information, we can create the backup job!

File-Based Backup Example: Creating Backup Job

We can combine this into a nice script as follows:

Create a Scheduled File-Based Backup

Let’s now take a look at creating a scheduled backup job with PowerCLI.

Following a similar process to the last task, we will want to use one of the services we found previously called: com.vmware.appliance.recovery.backup.schedules

This time, we see two inputs are required. First, the schedule ID. Second, the specification which is similar to the prior example. The ‘Help’ property will be quite useful to create both specifications.

Much like the prior example, this one too has some caveats. The Schedule ID input can be a string of your choosing. For reference, performing this process in the UI creates a default ID of ‘default’. The scheduling recurrence configuration can be done in many ways through the ‘days’ property. If a daily backup is desired, there’s no need for any input and it can be left ‘unset’. If a specific day/s are desired, the input has to be of an array type.

Here’s a script which can be used to create a scheduled file-based backup:

Afterwards, if you log into the VCSA Appliance Management Interface (VAMI), your backup schedule should look much like the following:
File-Based Backup Example: Creating a Backup Schedule

Summary

The ability to create file-based backups of your vCenter Server is a function that is only available to the VCSA. This function is made possible by a set of RESTful APIs which PowerCLI can also consume, with the additional benefit of not being reliant on the root account! This blog post walked through examples of creating a file-based backup job and creating a scheduled file-based backup job.

More information about VCSA file-based backup can be found on the vSphere Central site: vCenter Server Appliance 6.7 File-Based Backup

Let us know in the comments how you’re automating your VCSA backups!

Automating Sysprep File Transfer to vCenter

I was at my local Salt Lake City VMware User Group (VMUG) last week doing a Q&A when one of the users mentioned it is painful to only be able to upload one Sysprep file at a time to vCenter. I wanted to take the time to address this for him as well as any of you who may have the same issue.

Problem: uploading Sysprep files to vCenter only allows for one file upload at a time. Continue reading