In our last post, we looked at some SMBIOS based asset information. In this post we'll start to explore what information is available from IPMI.
As with our previous posts, lets explore the relevant technology a little before we dive into code. IPMI – the Intelligent Platform Management Interface, is a specification that defines how you can monitor and manage the health and hardware assets on a system using what is called a Baseboard Management Controller or BMC. The BMC is a secondary processor/controller that runs in the system and typically has it's own power tap on the power supply, so it's live even when the main system is powered off (as long as the power supply is plugged in.) Most modern server class x86 systems come with a BMC that supports IPMI. The BMC is then hooked up to various sensors and components on the system and can monitor their state independent of the primary CPU and running operating system. Some examples of the types of things BMCs may monitor are chassis intrusion sensors, temperature sensors, presence sensors for devices like hot-plug disk drives, and power supplies. Often the BMC is available on the network through a secondary IP address and can be used for remote management of the system, even if it is powered off (say to power it on – a capability which vCenter's Distributed Power Management feature leverages.) We're not going to focus on remote IPMI in this post, but instead look at the types of information you can retrieve from the BMC via the CIM implementation within ESX. The IPMI specification provides a lot of flexibility to system manufacturers in the type and number of sensors they implement. As a result, the data you see on one system may not match the data you see on another, particularly if those systems are from different manufacturers.
IPMI data maps to a number of different profiles. We'll take a look at two in this set of example code, namely DSP1009 – Sensors Profile, and DSP1015 – Power Supply Profile. In this example, we'll also touch on another aspect of CIM technology that can be a little tricky for beginners. The CIM schema often relies on enumerated types, or as CIM refers to them, Value Maps. When you look at the value of a property in an instance, it may be numeric, but that maps to some well defined set of values that are captured in the class definition in the MOF. Lets look at the HealthState property as a simple example of how this works. Here's an excerpt from the CIM_ManagedSystemElement MOF where this property is defined.
[Description (
"Indicates the current health of the element. This "
"attribute expresses the health of this element but not "
"necessarily that of its subcomponents. The possible "
"values are 0 to 30, where 5 means the element is "
"entirely healthy and 30 means the element is completely "
"non-functional. The following continuum is defined: n"
""Non-recoverable Error" (30) – The element has "
"completely failed, and recovery is not possible. All "
"functionality provided by this element has been lost. n"
""Critical Failure" (25) – The element is "
"non-functional and recovery might not be possible. n"
""Major Failure" (20) – The element is failing. It is "
"possible that some or all of the functionality of this "
"component is degraded or not working. n"
""Minor Failure" (15) – All functionality is available "
"but some might be degraded. n"
""Degraded/Warning" (10) – The element is in working "
"order and all functionality is provided. However, the "
"element is not working to the best of its abilities. For "
"example, the element might not be operating at optimal "
"performance or it might be reporting recoverable errors. n"
""OK" (5) – The element is fully functional and is "
"operating within normal operational parameters and "
"without error. n"
""Unknown" (0) – The implementation cannot report on "
"HealthState at this time. n"
"DMTF has reserved the unused portion of the continuum "
The metadata in the square brackets that precedes the property is called "Qualifiers," which are typed metadata in CIM. This particular property has 3 qualifiers, "Description," "ValueMap," and "Values." Let's focus on the latter two. What this pair of qualifiers tells us is that we can interpret numeric values as the logical equivalent of the English strings captured in the Values array. These two arrays are correlated – so "0" maps to "Unknown," "5" maps to "OK," and so on. Lets look at an example sensor using the same algorithm from the code we looked at last time. (Hint – to try this out, just change the classname to CIM_Sensor in the previous posting's code.)
You'll notice that HealthState is reported as "5" which if we look back at the MOF, represents the value "OK." Now lets look at a little snippet of code that can help output these properties in a more human readable form.
if 'ValueMap' in qualifiers.keys() and 'Values' in qualifiers.keys():
vals = qualifiers['Values'].value
valmap = qualifiers['ValueMap'].value
value = instance[propertyName]
# Find the matching value and convert to the friendly string
for i in range(0,len(valmap)-1):
if str(valmap[i]) == str(value):
mapping = ' ('+vals[i]+')'
break
return mapping
Now if we call that new routine from our printInstance routine when we display property values, we can display friendly values for these properties as well. Here's the same instance from above with the new logic in place.
