"UCSQL"   :  Just the Beginning

Blog Post created by jesilber on Jan 29, 2014


“UCSQL”.   Rolls right of your tongue, doesn’t it?    It puts “UCS” in a relational context (i.e. “SQL), which is exactly where it belongs.   The deeper you understand the UCS Manager, the more this makes sense. Want to get more utility and understand more about the UCS Manager?  Great! Here’s a new tool to help you.


For the past 5 years, I’ve made it my mission to help people better-understand the Crown Jewels of the Cisco Unified Data Center Solution:   UCS Manager and the UCS Management Model.   Arguably one of the most valuable aspects is the inherent “programmability” --- where all the server infrastructure and connectivity can be programmed using  the XML/API.   I’ve been a strong advocate that customers take full advantage of this capability --- to automate workflows and operations, as much as possible.  And as the author of the UCS Central Best Practice Guide,  I wanted to encourage the same level of programmability for UCS Central.   For example : “How can I script global inventory collection across all domains?”,  or “How can I programmatically get a list of all the backup files, so that I can copy them offline?”,  or “I want a script that shows me all service profiles in all domains, along with any associated blades”.


Both UCSM and UCS Central are “relational” engines.   But up until now, there has been no classic “relational” access method --- like SQL, which many people speak.    A traditional database engine creates data dictionaries that tell you the meta-data about the tables, like the column names.   But UCSM and UCS Central aren’t classic database engines --- instead, the meta-data is only kept in the code-generated schema files, which are dynamically generated when UCS Manager is built by Cisco Engineering (and then used as the input for creating UCS PowerTool, UCS Python SDK, etc.)   You can see the meta-data dynamically through “visore” or through the UCS Platform Emulator --- but you can’t see it in an interactive scriptable manner. 

The main UCS XML/API operation to “query” objects (“configResolveClass”)  is opaque --- meaning that without leveraging the schema files, the UCS Data Management Engine (DME) will not tell you the attribute names in advance --- it will simply return all attributes and values. 











Classic database engines have a “show” or “describe” operation, to help selectively choose which attributes you want to project on the “select” statement.    So then for UCS, how do you answer these questions in a scriptable, programmatic manner:

  • What are *all* the Class Names?
  • What are the attributes for a given Class?
  • What are the current values of specific Class attributes?

I could not find an appropriate tool --- so I started making one myself.   And given enough time flying to various UCS User Groups, I was able to construct a way to answer these questions --- and offer a more general/extensible framework :  “UCSQL” ---  a Python-based scripting tool that accesses the UCS DME using SQL, translated over the XML/API.  


Now, I can explore the UCS schema with statements such as “show All", "show lsServer”,  “show vnicFc”,  “show orgDomainGroup”,  or see all the UCS backup file locations in UCS Central with “select * from configBackup”, or pre-provision my SAN configuration with “select dn, addr from vnicFc”, or pre-provision my IP mapping with “select dn, addr from vnicEther” --- along with several other examples and sample output.


And so can you. Because “ucsql” has been released as a UCS Community Source Project.   It’s yours.    The source code is being hosted and can be downloaded from github here.   Any questions?  If so,  just visit/post the community at

Very interesting footnote here :  “ucsql” can be used against UCS Manager (single domain) or UCS Central (many domains), or UCS C-series XML/API  [ “What?!?”].     Yes, because all three share a common XML/API and all three share a managed-object model that uses the same names for objects, when possible.   If you want a quick report on firmware versions or faults, it’s just “select * from firmwareRunning”, or “select severity, descr, cause, created, type, dn from faultInst”.   Works equally well when talking to UCS Central, UCS Manager or UCS C-series.    Really.


Sound interesting? Well hopefully, it’s just the beginning.   There’s a lot more functionality that *could* be added, but it needs a development community.   That’s you.    Here’s a great opportunity for you to define, engage and participate directly in developing a new UCS Management access tool that you get to use for your own advantage.     And that’s the bottom line for “ucsql” and UCS in general :  greater utility for you.