Cisco Blogs

If you can do it in UCS Manager GUI, you can do it in UCS Manager API!

August 2, 2012 - 0 Comments

If I have said it once, I have said it at least a thousand times. No figure of speech here, completely one hundred percent literal. What have I said? “If you can do it in UCS Manager GUI, you can do it in UCS Manager API!” Whatever “it” is.

When do I say this? Whenever I talk about the UCS Manager to customers or coworkers, there is almost always the question, “Can this be done via the API?” To which I always reply “If you can do it in the GUI you can do it in the API.” Not sure if that is grammatically correct, but my point is made. That is the power and the ease of the UCS XML API.

The UCS Manager graphical interface is built on the XML API. When developing a script and you’re not sure how to do the action, what the call is, what the correct parameters are, etc… Just look at how the UCS Manager does it and you’re good. How do you look at how UCS Manager does it? Use Wireshark or some other packet capture tool and see what’s going on, what is getting passed from the UCS Manager client to UCS Manager. Done, no secrets, no convolution, no obfuscation.

Now there are several tools available to interact with the UCS where you don’t have to write any code. Check these out.

  • UCS PowerTool
  • goUCS Has been deprecated
  • PowerShell without UCS PowerTool (not sure why you wouldn’t use PowerTool)

I’m going to use a hybrid of UCS PowerTool and .Net to do something that I didn’t realize could be done via the API, until I had an aha moment. The aha moment was when I viewed a Server SEL log in the UCS Manager client. I had been asked previously how to retrieve the SEL logs from the UCS, and have shown users how to go into the CLI and get the SEL log and send it somewhere in an automated fashion using expect.

Now, I realize that I was ignoring my own adage, “If you can do it in UCS Manager GUI, you can do it in UCS Manager API!”

I started Wireshark and viewed a server SEL log in my UCS client. Interestingly, this call was not an HTTP POST as normally happens with the UCS XML API, but an HTTP GET. Almost all UCS XML API calls are HTTP POST, so when an HTTP GET shows up I think hmmm, not going to be the usual process, because actually it is not a UCS XML API call. The request is a standard HTTP GET, there is a file on the UCS Fabric Interconnect, go GET it. But what about authentication, don’t I need a UCS authentication cookie?

When looked at the captured HTTP GET I do see that there is a header element called Cookie and it is set to “ucsm-cookie=” and the GET URI is a bit different. The GET URI has /../ in its path, this seems to be required because when I attempted to get the SEL without the /../ in the GET URI path I received an error.

This is the GET URI path for Chassis 1/Server 1

For a Rack Mount UCS server that is being managed by UCS Manager the GET URI path for server 1 would be

So this turns out to be fairly simple to do, you’ll need a few items

  • UCS Authentication Cookie (which means a connection to a UCS)
  • The Server number for the SEL to be retrieved
  • A .Net System.Net.WebClient Object

That’s it, while I’m sure you’ll wrap this up is a script with input parameters like username, password, UCS name, output file name, debug flag, the usual stuff. I’m just listing the commands as if entered right at the command line. This example is for Chassis 1/Server 1, I’m using the UCS PowerTool cmdlet Get-UcsPSSession to get the UCS ucs and the UCS cookie attributes from the UCS session object.

$httpGet = New-Object System.Net.WebClient
$httpGet.Headers.Add("Cookie", 'ucsm-cookie="' + $(Get-UcsPSSession|Select-Object -ExpandProperty cookie) + '"')
$httpGet.DownloadString($(Get-UcsPSSession|Select-Object -ExpandProperty uri) + "/ucsm/../operations/server-1-1/sel.txt")

There also are settings in UCS Manager for moving the SEL files to a host based on time, service profile change, file size, etc.

Just remember “If you can do it in UCS Manager GUI, you can do it in UCS Manager API!”

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.