I recently worked with a client who has a critical inventory of AIX servers supporting their business. Baseline discovery cannot discern between AIX servers, and VIOS servers which are special releases of AIX dedicated to managing IO. This makes it impossible to manage the lifecycle of those VIOS instances. In this article, I discuss a simple pattern extension which provides improved visibility to these VIOS servers and their version.
AIX servers carry a bit of class baggage with them which is often overlooked. While you can discover AIX servers alone, you derive significantly more value by treating it as an IBM Power stack. The key class layers are as follows:
IBM HMC Server [cmdb_ci_hmc_server]
IBM Frame [cmdb_ci_ibm_frame]
IBM LPAR Instance [cmdb_ci_lpar_instance]
IBM VIOS Server [cmdb_ci_ibm_vios_server] (not currently supported by Discovery)
AIX Server [cmdb_ci_aix_server]
This stack begins with HMC Server discovery (top-down). HMC Servers are responsible for managing the underlying hardware virtualization on IBM Frames. An IBM frame is a collection of hardware resource which can be allocated to logical partitions (LPARs). It's important to capture these in the CMDB as they are expensive hardware components with serial numbers that are used to derive downstream LPARs and servers.
The second phase of hydrating the Power stack is initiated from the AIX server discovery (bottom-up) which populates both the server and its associated LPAR. The LPAR is a virtual machine that hosts the AIX operating system.
There is a special variety of LPAR called a VIOS Server. It's function is to facilitate I/O channels for other LPARs on the frame. Unfortunately, this class is under-represented in baseline Discovery capabilities in that it is indistinguishable from standard AIX servers within the cmdb_ci_aix_server table.
VIOS servers can only be identified by checking the is_vio field on the related LPAR instance (cmdb_ci_lpar_instance). Unfortunately, this isn't sufficient to manage the lifecycle of these servers because it's not returning the correct OS type of version on the server.
AIX administrators need more than a true/false attribute. A VIOS server classifies as an AIX server, and responds to all of the AIX commands which the AIX Server pattern executes. However, it is really a VIOS server which runs a special version of AIX as it's foundation. That VIOS server is managed as its own operating system (VIOS) which has its own lifecycle and version that does not match the underlying AIX release. Our objective was to make it easy for AIX administrators to see which servers were actually VIOS servers, and to expose the VIOS version.
Design decisions became interesting at this point because there is a CI class for VIOS servers [cmdb_ci_ibm_vios_server]. This class is not supported (yet) by any baseline patterns, nor are there any suggested relationships established in the data model, or even classifiers. While we could create any of the objects needed to hydrate this class, all of those objects would become technical debt that the customer did not want to maintain.
The baseline AIX Server pattern met our requirements with three exceptions:
- The OS name reports AIX, when we want to see an indication of VIOS.
- The OS service pack attribute is relevant to normal AIX, but not to VIOS.
- The OS version reports the AIX version rather than the VIOS version.
We can address all three requirements through a simple pattern extension. By using an extension, we avoid technical debt by not modifying any of the baseline pattern objects.
The baseline "LPAR Discovery" extension executes the ioslevel command to return the VIOS version we need to expose. Unfortunately, although that command is executed, its return value is never used by this pattern; Instead, it only looks at whether or not it is populated.
Shortly after that, the LPAR Discovery pattern sets the is_vio attribute on the cmdb_ci_lpar_instance table, and that bit of data is available to subsequent patterns, enabling the logic we need to support VIOS visibility.
By leveraging the is_vio variable we know whether or not the LPAR associated with the AIX server hosts a VIOS operating system, and if so, what version it is running. These values can then be used for a new pattern extension. The extension has four simple steps:
In the first step we will gracefully exit if the related LPAR instance did not set the is_vio flag. We include a message that is easy to interpret in the Discovery logs:
In step 2 we execute the ioslevel command to capture the version of VIOS and store it in a temporary variable. Unfortunately, the prior execution of this command isn't available to us in this extension so we need to run it once again.
In step 3 we modify the values in the aix server table to include the VIOS version, overwriting the AIX version which was installed by the identification section's pattern. I chose the label "AIX VIOS" because when viewing these Cis from an upstream class like cmdb_ci_server, this provides an easy way to see it near AIX when alpha-sorted. It also provides an indication that it's an AIX related OS if someone less familiar with the Power stack is reviewing data.
In the last step we blank out the os_service_pack value which was populated by the earlier identification section because this value is not relevant to the VIOS version.
This pattern extension should be installed with an order which enforces execution after the baseline LPAR discovery extension.
The end result of this pattern extension is that we can easily see AIX VIOS server OS and its related version when scanning the class. We were able to do so without creating any technical debt on the baseline AIX patterns, or having to own a custom classifier probe/sensor and pattern to populate a dedicated VIOS class.
I'd enjoy working through that more extensive exercise in a future project, but I feel that this simpler approach met specifications far more efficiently.
