In this blog post, I describe a root-cause detection scenario using IBM SmartCloud Provisioning.
Given the ever increasing number of virtual machine (VM) instances and VM images in a cloud ecosystem, it is becoming more and more important to track content and configuration of each of virtual image, mainly for standardization and consolidation purposes.
Another situation when tracking this content that might also be useful is to identify the “drift” between a deployed virtual machine and the virtual image that was used to create it, as in the scenario described next, for example.
As soon as a virtual machine is deployed from a virtual image, its content starts to change; the owner of that virtual machine begins using it by creating new files, by using its applications, by installing or uninstalling software, and so on.
Because of any of these actions, the system or a specific application might no longer work correctly. At this point, something you could do to understand what might be the cause of such malfunctions is to identify all the changes applied to the instance compared to the source virtual image; then try to identify the “culprit” change in order to take appropriate actions for repairing the situation.
This is a typical scenario where the IBM Virtual Image Library component of IBM SmartCloud Provisioning can help—through its indexing and drift analysis capabilities.
As already highlighted in a previous blog entry, the IBM Virtual Image Library is a tool that provides sophisticated image-management capabilities that customers can use to tackle the difficult issues of understanding and controlling the contents of their virtual infrastructures.
Let’s see how this tool can help in troubleshooting our scenario.
- The first step is to identify the failing virtual machine among those available in the IBM Virtual Image Library repositories. The tool continuously indexes the configured repositories of virtual machines and images so that its data model is always up-to-date with the actual content of the virtual infrastructure.
- After the virtual machine has been identified, the next step is to retrieve the virtual image from which it has been deployed. This is another feature provided by the tool that keeps track of the entire tree of relationships among virtual images and virtual machines available in the environment.
- The next step, if not already previously done, is to run an indexing operation of the virtual machine so that its content, in terms of installed applications, OS information and file-level information can be retrieved and brought into the tool’s data model.
- After the indexing is complete the source virtual image content and the virtual machine content can be compared. A list of differences is presented so you can review them and decide which differences might be the most likely reason for the problem.
For example, from this report, you might notice that a suspect application has been installed into the virtual machine that shouldn’t be there or that a configuration file, used by the application that is malfunctioning, has been modified.
You can use these hints as a starting point for troubleshooting the issue and for taking repair actions.
The Virtual Image Drift Analysis Using IBM Virtual Image Library movie demonstrates, by means of an example, the capabilities I’ve described.
What I have described is basically an example of the drift analysis capabilities of the IBM Virtual Image Library with the intent to give you an introduction to the advanced features of this component. If you are interested in understanding more deeply how the IBM Virtual Image Library works and to have a summary of all of its capabilities, read the following paper:
“Standardize image management with the IBM Virtual Image Library”