11 golden rules for virtualisation

5 Aug 2010

Steve Cassidy distils wisdom based on years of virtualisation into 11 simple rules

Virtualisation has many benefits, but there are also many hurdles to making your system work smoothly - the jargon alone can be confusing.

Here's our top 11 tips to help you make the right decisions for your virtualistion project.

1) It isn’t just about the box

Virtualisation projects pay back by reducing power bills and server purchase budgets. The latter is easy to demonstrate; the former requires some distinctly non-computing work.

To really see the benefit, you have to be able to compare hosting rack-space invoices, or monthly electricity bills, or stand in the blast of the cooling fans – it’s very difficult to translate the massive efficiency improvements into something tangible. The most basic fat-plug current meter can form the basis of a good solid demo for that disbelieving finance director, standing in the server room watching you start up the old boat-anchors and chalking up their power draw on the wall.

Learn more

Free webcast: Sign up to see our free on-demand webcast aimed at demystifying business data storage and backup.
Hosted by PC Pro's David Fearon with guest experts from Dell, Microsoft and EMC. Registration takes one minute.

Thinking about your project in these terms also helps to understand the logic behind the management and monitoring tools (the stuff you have to pay for). It can seem almost incomprehensible to look at the “MHz Used” bar chart in vSphere 4 if you haven’t started by working through from the electricity meter, through to the old servers, and then on to the new virtual host.

2) Find your tribe

Are you top-down? Bottom-up? Custom-build or preservation order? Linux or Windows? Server or desktop?

The variety of ways in which virtualisation projects can be distinguished is confusing mainly because the design of the tools fit into a much wider philosophy of process – and if you’re comfortable with one way of passing through a virtualisation project, that’s probably the strongest determinant of the hypervisor, method and toolbox suite you should plump for.

Jargon buster

Hypervisor: The piece of software that provides an environment in which guest virtual machines can run. Not terribly large as software goes, but very complex indeed.

Bottom up: Taking the software installs, and going through them inside a hypervisor to make a new instance.

Top up: Taking a running physical server and converting it into a virtual copy.

Note that the real trouble begins when the lead techie in a business comes from the “Linux, top-down, hot-swap” tribe, when the business itself actually needs a “Windows, bottom-up, build to last” deployment. And yes, we’ll be using other rules here to help you reach that decision.

3) Prototype like crazy

Irrespective of which tribe you’re in, and no matter what the forums may tell you, the “hole in one” virtualisation (where your first try comes up hale and hearty and runs for the next decade untouched) is limited to a very narrow range of candidate networks and servers. Think Exchange 2003 and earlier versions – and that’s about it.

This means building up a single-user machine able to present your virtual server or collection of servers away from your live network, so you get some idea of what’s going to happen when you push that button.

This in turn means being familiar with the product ranges of the hypervisor maker you’re choosing – are you about to test an eight-core VM on a workstation version of the hypervisor that will present only two cores?

It can be possible to prototype on production servers alongside live running processes – VMware Server for Windows pretty much made its reputation this way, for good or ill – but the consequences of getting this a bit wrong are considerable.

Read more

In-depth