There's a script for that: PowerShell automation for Cisco UCS PowerTool

Windows PowerShell is all about automation. I was reviewing some Cisco Unified Computing System (UCS) videos, and came across a few sections where the presenter says something along the lines of “and now do that for every--.”  I paused the first time I heard that to do some mental math, and then I told myself, “I have to script that.”

 

Cisco UCS PowerTools

I've talked about Cisco UCS and PowerShell on this blog before, and I provided an overview of the PowerTools, the UCS emulator and also the quite handy ConvertTo-UcsCmdlet.

Unfortunately, the built-in help documentation that comes with the PowerTools is a bit poor, but with the help of the ConvertTo-UcsCmdlet, I was able to figure out some of the cmdlets I needed in order to do certain things.

 

Cisco UCS emulator

I will be using the Cisco UCS emulator to run my commands against. Some of the results weren't exactly as I had expected, and I wasn't able to do a full run through of the Cisco videos because you can't actually apply a firmware upgrade to the emulator, for example.

 

First things first: Where's my backup?

I'll be using the Cisco UCS emulator to go through the exercises here. Let's assume I've already connected (look at Connect-Ucs in my other post if you need a refresher).

So, all I need to do to take a backup like in the Cisco video is to issue the command:

I decided to save the results of the command to a variable. I did need to review the help notes for the cmdlet to find the PreservedPooledValues switch, as the UCS Manager UI names it as “Preserve Identities”.

 

Checking the current status

Next, the video recommends checking the status of each of the fabric interconnects. I don't find some of the naming of their cmdlets to be really user-friendly, but I eventually came across this:

I could have dug in a bit deeper or filtered out the results. I'm primarily concerned about the status of the objects named “Fabric Interconnect” in the above output.

Afterwards, Cisco's video instructs you to check things like the local storage and high availability status of the fabric interconnects. I searched around and wasn't able to find a way to get this from PowerShell. I also reviewed the XML API information briefly, but didn't have any luck.

 

Checking the IO modules

Cisco's video then goes on to ask that you check the status of the IO modules, which is easy:

The IO modules in the chassis are noted as “UCS-IOM” above, while the others are associated with Cisco Nexus virtual switches (all part of the default configuration of the UCS emulator).

 

Verifying the status of other components

Some more things to check include the status of the servers (aka “blades”), adaptors, virtual Ethernet and fiber channel interfaces.

I'm showing all of these checks below. Since they would take up quite a bit of space, instead of listing everything I decided to only list something that was an exception. This was really easy to do by trying to match where the property value of “OperState” was not “operable” as shown:

Again, since this is using the Cisco UCS emulator, I might expect to see something a bit different in a production environment assuming it's actually fully provisioned.

 

Don't reboot the blades!

In the second video from Cisco, there's a slide that warns about the firmware maintenance policy.  Basically, you are warned about this policy being set to “immediate” or “user acknowledge”.  If you understand the implications of the former, and have strict maintenance windows, you definitely want to make sure you understand this one in a production environment.

Below, I'm just playing around with my profiles and policies, but the important thing to note in the “UptimeDisr” property value is that I have this maintenance policy set to “user-ack”, which basically means “prompt me before you disrupt service.”

You would probably want all of your profiles to have this user acknowledgement requirement before you start applying any firmware updates to any of your blades.

 

What else is possible?

I've covered how to automate some of the checks that are recommended in the video. You can definitely take this several steps further. For example, you could potentially automate the checking of the firmware update versions, possibly this way:

Some other things that could be useful is saving the output from the above commands to either produce a report or to help you compare the before and after status.

Just imagine if you had either Microsoft Hyper-V or VMware virtualization running on a Cisco UCS platform. Not only could you automate the patching and updating at the hardware level using PowerShell, but you can also interact with the virtualization platform to shift virtual machines around while the blades are being rebooted to apply the firmware updates. With PowerShell you can do this all with no downtime at all.

 

Your trial includes access to our course on Implementing Cisco Unified Commuications System!