The 4 stages of virtualisation

As virtualisation becomes more popular, and as I’ve done a few projects with this myself and both helped and watched others do virtualisation projects, I think there are probably at least four stages to the life cycle of virtualisation within an organisation, and I thought it might be interesting to compare and contrast them. It’s important to remember that while some organisations will go through all the stages, others will skip certain stages, and its very important to remember that the stages are standalone goals in their own right; its perfectly reasonable only complete the first stage listed below and stick with it if that is all the business needs to do.

Stage One

Experimentation with virtualisation, using type two / hosted hypervisors like VMWare Workstation or Microsoft Virtual PC in order to create a few virtual machines running in the "spare capacity"  on non-virtualised production machines.

This is actually a good first stage for anyone contemplating virtualisation without understanding too much about it, as it offers a chance to become familiar with the concepts behind virtualisation without having to commit dedicated hardware or resources. A possible downside of this approach as a “first step” is that people might confuse limitations of virtualisation at this level (virtual machines on top of a normal system) with limitations of virtualisation in general.

This is also useful for smaller businesses for whom this level of virtualisation is both easy to set up and support and “good enough” for their needs. It’s also very useful for support staff who may need to be able to emulate a number of different customer environments in order to re-create customer support scenarios.

Stage Two

At this stage a company dips a toe into full virtualisation (e.g. using a type 1/native  hypervisor such as HyperV or VMWare ESXi).

A typical implementation of this type might see one or two “stand alone” virtual hosts with locally attached storage used to virtualise one or two specific “virtualisation friendly” applications, or used as migration targets for old/legacy systems whose hardware has gone past its retirement age.

Often (and especially in the case of legacy systems that have been migrated to VMs) the virtual guest systems are not optimised for the virtual environment they are in, with resource allocation planned as if for a physical system, and (to varying degrees) optimisation of the guest OS for a virtual environment done poorly, if at all. This lack of optimisation may also apply to the virtual host hardware itself, and in both cases the lack of optimisation may mean that guest performance and availability is simply “good enough” rather than good.

Stage Three

This is the point where an organisation has invested serious resources in planning and implementing a virtual server configuration, not merely to fix a problem or as an upgrade path for obsolescent hardware, but in pursuit of the benefits of virtualisation in its own right.

This is typified by a group of virtual hosts using shared storage, and very possibly by the use of tools like VMWare vMotion / HyperV Live Migration to provide fault tolerance of virtual hosts to improve the availability of virtual guests.

As for virtual guests at this level, they might consist of a number of imported/converted virtual guests (as in stage two) and a number of newly created guests.  These guests are typically still sized as if they were still physical machines, so may not perform optimally in a virtual environment. This might be down to a mixture of administrator training/habits and the requirements of imported legacy systems that don’t react well to hardware changes.

Stage Four

At this point the organisation is wholly comfortable with virtualisation. Storage and Servers are purchased with an eye to how they fit in to the virtualisation strategy, and support for virtualisation starts to be a factor in the selection of operating systems and server applications.

The virtual hosting environment is well managed (by which I don’t mean that the most expensive or complicated tools are installed regardless of requirements, but rather that appropriate tools are installed). In larger organisations there may be a separation of administration duties for the virtual environment vs. guests in the environment, and in any case the virtual hosting environment is managed in a structured way, rather than being treated as an overhead in the management of the guests it holds.

Virtual guests are properly sized for the environment at this stage, with both capacity planning and resource usage monitoring done with the needs of the virtual guest vs. those of the other guests on that host taken into account.

When should you move from one stage to another?

Stage One to Stage Two or Three It's questionable if a migration path exists from this stage to the other stages at all. This stage is a perfectly satisfactory and achievable goal for small businesses who just want to make better use of hardware that's already in production (though I might urge you to consider "stage two" virtualisation when you come to replace this system). It's also quite possible to set up a system of this kind to get to grips with virtualisation if you're new to it, then realise that you need shared storage and high availability and go straight for a "stage three" system in your datacentre.

It probably makes the most sense to consider stage one as a separate branch entirely in the evolution of virtual machines - despite having a reasonably sophisticated “stage three” virtual environment ourselves, we still use stage one technology separately, as test beds for developers and technical support staff who need to create custom test environments.

Stage Two to Stage Three This is an interesting one, and could illustrate how investment in IT is considered in your business, as it is a big step to go from standalone virtual hosts to ones with expensive integrated management tools, shared storage and complex networking arrangements.

The question is: when do you make the changeover from standalone to integrated? There’s not many sadder sites in IT than the business that thinks its saving money by staying at stage two way past the point where it should have migrated… unless its the business that spent a fortune on a “stage three” system with half a dozen virtual hosts sharing a top of the line SAN… with three guests running on it. And before you ask, I have seen both these situations in the wild.

Stage Three to Stage Four This is possibly the one migration that should be considered mandatory as this isn’t as much about buying more hardware or software, as it is about making proper use of the resources you already have. I’d suggest that this step should be part of the natural refinement and improvement of processes that you’d expect once any system upgrade has taken place and the dust has settled.

The only question for me is whether or not you would make this process of refinement a specific project objective (and you may well have to in order to realise the benefits you promised management if you got a little carried away with your estimates of how much hardware/floorspace and power savings your virtualisation project will deliver) or if this is something you simply expect to happen as part of the natural life-cycle of any new system you implement.