Cloud systems have made a huge
improvement in terms of tracking and performance. In “Rapid deployments with
IBM Smart Cloud Provisioning” blog, we have shown that virtual machines or
appliances can be started and configured in a matter of seconds. It has never
been so easy to create a virtual machine (VM), install software, and configure
middleware. However, with great power comes great responsibility… it is now
possible to create a VM, but what is its lifecycle? Will it be destroyed after
being used, is the starting image deprecated, or is there a better starting
image given the needed configuration and software install requirements?
IBM SmartCloud Provisioning provides a component called IBM Virtual Image Library (also known as IVIL) to solve common issues that arise in large scale virtualized environments:
- Image tracking: Where are my images? How old are they? How are they related?
- Content and security: What is in the images? Are they secure? What is the software stack installed?
- Redundancies: Are there images redundancies? Is there any difference between two images?
- …the list goes on
VIL can be integrated simply into
your virtualization infrastructure; the only requirement to start using IVIL is
the credentials required to contact the virtualization infrastructure. No changes to your current virtualization
environment are required. After credentials
are provided, IVIL can automatically determine the provenance, state, and the
content of each virtual image or virtual machine in the virtualization
environment. After the environment is
registered you will have a clear picture
of your various images, their content, history, and similarity with one
another. More important, as soon as IVIL
is used in the infrastructure, it can be used to move the images from one
hypervisor vendor to another and keep track of these migrations. To summarize, IVIL
not only keeps track of the changes of an image on one hypervisor but continues
when images are in a heterogeneous environment.
A common solution to track the contents and versioning of images is by use of a naming convention, for example, a name such as RHEL_6.1_WebSphere7.1_v2.1 implies the image is Red Hat Linux 6.1 with WebSphere 7.1 installed, and that this is version 2.1 of this image. It is feasible to use this approach with a small number of images but becomes cumbersome and confusing with anything but small examples. Basic information that is typically attempted to be conveyed includes:
- What is the OS and OS version?
- What applications are installed and their versions?
- Are the latest patches and updates installed?
- How does this image relate to other versions of the same or similar images?
Using an image naming convention can work in some cases and provide some of the needed information but it does not scale beyond a small number of simple images. To solve this, IVIL provides versioning and provenance control to understand where an image comes from:
What is provenance? Simply put provenance tracks the history of the image as it has evolved over time in the virtual environment. It tracks how the bits that make up the image came to be – through IVIL checkout operations, image clone operations, image copy operations, and so on. It is used to understand the lineage of an image from the perspective of the virtual system which might or might not match with how the user of IVIL views the image.
For example, let’s assume that you
have an image called “A”. If you decide to start this image on multiple
instances of IBM SmartCloud Provisioning or if you decide to clone this image
possibly multiple times, then IVIL will keep track of the relation between all
the created images and instances. At any time, if a security flaw is found on
A, then you can infer that the associated images and instances are likely affected
also. IVIL provides this functionality not only for a single virtual
environment, but across heterogeneous virtual environments also.
What is versioning? Versioning is the logical user-defined lineage of an image or virtual appliance; it is the way a user would think of versioning his or her image functionality, for example this is version 2 of my AccountsPayableService virtual image. When an image is available with a particular application version, the OS and libraries behind are often not important, only the application is. Is it important to know its template? Not necessarily, only the information about the OS is relevant. However, it is good to know the application version and if there is a newer version available for this image or if a new image has been released with the latest security patches. This is the versioning system in IVIL; it helps to understand if there are other versions of the application in the infrastructure, if some applications contain a patch or not.
To summarize, provenance is
oriented to infrastructure administration whereas versioning is more oriented
towards applications and workloads.
For example, let’s assume that we want to provide version 1.0 of software S as image. By default, users can decide to use software S and trigger any instance of image A. At a certain point, the version 1.0 is deprecated and we must upgrade software S to version 1.1. Unfortunately, the OS distribution must be upgraded. A solution is to reinstall the OS from scratch and install S version 1.1 on it; this new image will be called B. These images do not have any common lineage from a provenance perspective, however the content has a logical lineage to the user. Image A is the parent of image B from a versioning perspective.
It is important to understand that
an image can have only one provenance parent but can have multiple version
parents. The second claim makes sense because an image may have multiple
applications installed and thus each one may be associated to a logical
This concludes the introduction of Virtual Image Library component in IBM SmartCloud Provisioning. Next time, I will introduce the concept of similarity between images and the power that it provides in terms of debugging, infrastructure consolidation, licensing cost, and more.