Change Management. “We didn’t submit a Change Request because it was a simple change. There’s no way it should have caused the server to crash!” I hope you never hear these words and with an enforced Change Management process you never should. Unfortunately, despite the fact that Change Management is one of the processes that most profoundly affects IT Operations, it is also, at least in my experience, one of the least enforced.

The ease with which virtual machines can be created and deployed coupled with the dynamic nature of virtualization makes Change Management’s importance even more pronounced. I believe a good practice is to have every virtual machine deployment approved via the Change Management process. This not only helps ensure that every group potentially affected by a virtual machine’s deployment – networking, storage, service continuity, the service desk, affected business unit(s), and, don’t forget security – will be aware of the deployment and have the opportunity to raise any concerns, but also imposes a level of control over the deployment process. In this way, forcing virtual machine deployments through the Change Management process goes a long way to addressing one of the bigger concerns with virtualization – virtual sprawl. In addition to virtual machine deployment, I would extend this enforcement to trusted, “golden” template changes as well. Without trusted golden templates, the risk of unstable and incident-inducing virtual machines increases dramatically.

The dynamic nature of virtualization, namely the ease with which virtual machines can be relocated, further compounded by the fact that this can be done automatically, presents another challenge I believe Change Management can help address. I posit that all virtual machine relocations be approved via Change Management until such time as the relocation of a particular virtual machine becomes routine. Once a virtual machine’s relocation becomes proven and routine, it’s probably safe to bypass the Change Management process. Furthermore, I would submit that you not automate a virtual machine’s relocation until the same level of routine comfort with its manual relocation is reached.

Configuration Management. Configuration Management is critical. From an ITIL perspective, Configuration Management is the core upon which almost all other ITIL-defined functions depend. Storing a virtual machine’s configuration information is relatively straight forward. The dynamic nature of virtual machine relocation, on the other hand, presents a unique challenge for Configuration Management. The issue is how to track something as simple as the location of a virtual machine when it can be easily, not to mention automatically, relocated. Until recently, I saw this as a relatively serious issue as it can directly impact other functions such as Incident Management, Capacity Management, and Availability Management just to name a few . Fortunately, a couple of manufacturers’ configuration management tools now offer a dynamic tracking feature that automatically updates the virtual machine’s location. These include HP and Microsoft via their use of nWare’s SPI.

One other ITIL Configuration Management construct I feel worth mentioning is the Definitive Software Library (now, in version 3, referred to as the Definitive Media Library). The Definitive Software Library is the repository where the authorized versions of all software are stored. In the context of virtualization, I suggest your trusted, golden templates reside here as well.

Capacity Management. Capacity Management is important in IT’s physical environment but I believe it takes on an even more critical role in the virtualized environment. At the simplest level, multiple virtual machines on a physical server means a capacity problem affecting the physical server can now affect multiple services. In addition, not only do you have to consider the resource requirements of multiple virtual machines per physical server, but the dynamic nature of virtualization again comes into play. With the capabilities provided by tools such as VMware’s Dynamic Resource Scheduler and High Availability, you not only have to consider the resource implications of multiple virtual machines on a single physical server but the impact on resources of moving virtual machines between physical servers as well. In doing so, you enter the world of resource pools extending across multiple, physical servers. And, to make matters even more interesting, in the case of Dynamic Resource Scheduler you can define multiple resource pools spanning multiple physical servers – the planning and management implications of which almost make my head hurt! Given the potential disaster one might face by changing resource pool definitions in this context, I would suggest approving resource pool allocation changes through your Change Management process as well.

Stepping away from the head-aching world of resource pools, storage-related Capacity Management also requires extra attention in a virtualized environment. Virtual machines are in all likelihood stored in your SAN; you can boot your virtual servers from a SAN, which imposes its own set of requirements; and swap files can be stored in your SAN – all requiring additional focus on planning and managing your SAN’s capacity.

Availability Management. The purpose of Availability Management, as defined by ITIL, is to ensure that the availability level delivered by IT Operations meets or exceeds the agreed-to service level requirements. Availability Management takes on an increased importance in a virtualized environment because multiple virtual machines per physical server means an availability problem on a physical server could potentially affect multiple services. A good first step is to perform a Component Failure Impact Analysis where the component is each virtual machine and the analysis is of the impact resulting from losing the service it provides. Based on this analysis, a decision may be made to implement high availability. High availability can be implemented for the servers hosting the virtual machines and/or the virtual machines themselves if loss of the services they provide is deemed intolerable.

You often find Capacity Management and Availability Management being considered hand-inhand. This is especially true in virtualization as once you move down the path of high availability resource pools will undoubtedly be involved. And, whether in a virtual or physical environment, shared disks as well as quorum disk placement from a storage perspective come into play which, of course, impacts storage capacity planning and management.