UCS Manager firmware version 1.4 now allows for the creation and download of Tech Support files in the UCS Manager GUI. These are the files that would have previously been created with the "show tech-support" command in the CLI and then subsequently transfered to a host via the "copy" command using
Lots of steps, ssh to the UCS, connect to the local-mgmt context, run the show tech-support, download the tech support file or files if you needed multiple components, ucsm, or chassis, etc...
Well once something is available in the GUI then it is available in the API, sweet. So break out your favorite protocol analyzer and start sniffing, at least that is what I do. I typically setup a few things when I start a scripting project
- Launch a session to a UCS, could be real or emulator
- Open a visore session for the UCS, http://<UCS-IP-ADDRESS>/visore.html
- Open the object model documentation, you get these with the emulator Get It!
- Launch a protocal sniffer and at least limit to http traffic, I use Wireshark Get It!
- Launch my IDE, I use eclipse mostly Get It!
- Launch Poster, Poster is a Firefox Add-on Get It!
- Launch XML Notepad, if I'm on my windows VM Get It!
Depending on the language I'm using my IDE might be eclipse or it might be PowerShell ISE. In eclipse I have setup custom perspectives to open the browsers for visore and the object model documentation. It might seem like a lot of things to launch/open, however I have found that I will need one or more of these during the course of developing something.
Back to Tech Support via the API, my last post showed how to automate running the "show tech-support" CLI command using expect, which is a great tool when the API solution isn't available. IT was somewhat limited in what kind of show tech-support you could run since i didn't take into account all the variations of components and sub-component options. That was left to the reader as an exercise.
How is the Tech Support supported in the API? The API is XML objects, the Tech Support is two new objects
The sysdebugTechSupport object defines the tech support, where it is on the UCS, when it was created, the fsm (finite state machine) values, etc...
The sysdebugTechSupportCmdOpt object defines what tech support options are used when generating a tech support file. Will this tech support be for a ucsm, chassis, fex, or rack server. Additionally some of the components have sub-component choices, like IOM selection under a chassis or rack server adapter id.
There are two caveats to creating and downloading a tech support file via the API. One is the use of a creation time stamp and the other is the use of http GET to retrieve the file. Up to this point all of our interaction with the UCS via the API has been http POST, however for this interaction we will use http GET to retrieve the file and save it.
Recently I wrote a script for a customer to automate the creation and download of a Tech Support file using PowerShell, incidentally a beta set of PowerShell cmdlets was just posted to the UCS developer website this past Tuesday 6/1/2011, you can get it here, PowerShell download
Whether you decide to use the PowerShell cmdlets, the Invoke-XmlCommand is what you'll use to push your XML to the UCS, or you write your own http POST method the flow will be the same.
This sysdebugTechSupport and child sysdebugTechSupportCmdOpt XML objects from my script
14 rn="tech-support-cmd-opt" />
See that 10 digit number at the end of the dn and as the value to the creationTS attribute. That is the number of Seconds elapsed since January 1, 1970 00:00:00. The way to get that in PowerShell is surprisingly easy, first you'll want the UCS time, not the time where you are running your script, run a configResolveDn query on "sys". The topsystem object is returned one of its attributes is currentTime. Use currentTime as an input to the Get-Date PowerShell cmdlet an then pipeline that through another Get-Date to format the output as seconds while stripping of the sub-second precision at the end of the returned value.
2<configResolveDn cookie="1307025819/e000ab65-a242-4133-b3fb-8ac05a91d95a" inHierarchical="false" dn="sys" />
5<configResolveDn dn="sys" cookie="1307025819/e000ab65-a242-4133-b3fb-8ac05a91d95a" response="yes">
13 systemUpTime="29:19:38:57" />
Grab the currentTime attribute value and use it as input to Get-Date, pipeline it to Get-Date and format then grab the first 10 characters
PS C:\Users\John McDonough> (Get-Date -Date "2011-06-02T10:43:39.388" | Get-Date -uformat %s).SubString(0,10)
Now that you have a creationTS you can build your sysdebugTechSupport and you can also build your sysdebugTechSupportCmdOpt object using values collected from command line parameters. The majorOptType attribute will determine what other attributes matter, here is a snippet of PowerShell parameter declaration that I used in the script
1 [Parameter(Mandatory=$true,HelpMessage="Enter a tech support type")]
3 [string] $MajorOptType = "ucsm",
5 [Parameter(HelpMessage="Enter Chassis ID")]
7 [int] $ChassisID = 1,
9 [Parameter(HelpMessage="Enter Chassis IOM ID")]
11 [int] $ChassisIomId = 0,
13 [Parameter(HelpMessage="Enter CIMC ID")]
15 [int] $ChassisCimcId = 0,
17 [Parameter(HelpMessage="Enter FEX ID")]
19 [int] $FabExtId = 1,
21 [Parameter(HelpMessage="Enter Rack Server ID")]
23 [int] $RackServerID = 1,
25 [Parameter(HelpMessage="Enter Rack Server Adapter ID")]
27 [int] $RackServerAdapterID = 0
Using the ValidateSet and ValidateRange, I can ensure that the values the script gets meets with the valid values stated in the Object Model Documentation. Also by setting a default value for the parameters I can ensure that the created XML objects will not be rejected by the UCS. Notice the MajorOptType will only accept the values "chassis, fex, server, and ucsm" also that the parameter is mandatory.
Once the XML objects are pushed to the UCS and the tech support creation process has started, your script needs to wait until the process is completed before it can down load the tech support file. The script I wrote checks for completion every 60 seconds by querying the sysdebugTechSupport object that was created and examining the operState attribute. When the operState value is available the the tech support file is ready for download.
21 uri="techsupport/20110602064339_ucs-as-rtp-6120_BC001_all.tar" />
The three attributes that are of interest are operState, name, and uri. operState tells me that the tech support file is available, name gives me a value to save my downloaded file to and uri gives me the path on the UCS to download from, I could extract the name from the uri or just use name. Either way I can get what I need.
Using the .Net WebClient object's DownloadFile method allows for the download of the file.
1$client = new-object System.Net.WebClient;
2$client.DownloadFile( "http://18.104.22.168/techsupport/20110602064339_ucs-as-rtp-6120_BC001_all.tar", "20110602064339_ucs-as-rtp-6120_BC001_all.tar")
The only real difference between the GUI version and my PowerShell version is that the GUI version waits for an Event Stream message (another blog) while my PowerShell queries for completion.
Hope this helps
Cisco Advanced Services