In this new blog post I would like to describe a root-cause detection scenario using IBM Smart Cloud Provisioning.
Given the ever increasing number of virtual machine instances and VM images in a cloud ecosystem it is becoming more and more important to track each of virtual image's contents and configuration mainly for standardization and consolidation purposes.
Another situation where tracking this content may also be useful is when there is the need to identify the "drift" between a deployed virtual machine and the virtual image that was used to create it, as for example in the scenario described below.
As soon as a virtual machine gets deployed from a virtual image its content will start to change; the owner of that virtual machine begins using it by creating new files, by using its applications, by installing/uninstalling software and so on. Because of one of the above actions it may happen that the system, or a specific application, may no longer work correctly. At this point one of the things that may be done to understand what could be the cause of such malfunctions is to identify all the changes applied to the instance compared to the source virtual image and look at them trying 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 Smart Cloud Provisioning comes at 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 a customer can use to tackle the difficult issues of understanding and controlling the contents of his virtual infrastructure. Let's see how this tool may help in troubleshooting the scenario we have described above.
The first step is to identify the failing virtual machine among the ones 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.
Once 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.
Once the indexing is complete the source virtual image content and the virtual machine content can be compared. A list of differences is presented to the user so that he/she can review them and decide what differences may be the most likely reason for the problem.
For example, from this report the user may 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.
He/she can use these hints as a starting point for troubleshooting the issue and for taking repair actions.
The following movie demonstrates, by means of an example, the capabilities described above.