The following blog post covers my thoughts on getting in to Virtualisation it was originally posted to http://www.taylord1.co.uk/; these comments are all off of the top of my head and may change in the future as I think more deeply about the subject.

As always, your mileage may vary.

Current Systems

My first thoughts on Virtualisation always start with what systems do we have currently, in my environment we’re 100% Microsoft platforms running almost 100% Microsoft software. This makes my life easier on the virtualisation side because I know that I will only need to support a single Operating System going forward.

At this point it’s always worth checking what service packs are applied to your machines; the service pack level can have significant impact on your choice of virtualisation platform

Virtualisation Technology

Choosing your Virtualisation Technology is a lot like getting married in my experience, sure the sexy tech is great in the first few years but you soon realise that you are stuck with the same technology day in day out for a very long time.

This makes choosing your technology an important step which should never be over looked, I know that many vendors now tell you that you can take VMware VM’s and launch them on Xen technologies and the like but in my experience when you do things like that bad things begin to happen, whether or not it’s simply that VM’s refuse to boot or something far worse like performance issues I’ve never had a good experience swapping around VM’s.

Your current infrastructure plays a role here too, in our environment we run Hyper-V we also run a series of Server 2003 machines with no service packs applied which do not play well in Hyper-V. Upgrading the Operating System on those machines isn’t an option at the moment and won’t be for a while, I’m sure everyone has certain workloads that simply won’t work on your chosen Virtualisation Technology.

Scope

It’s important to outline from the beginning exactly which systems you are aiming to Virtualise, it gives you something to point at one day and say ‘hey look, we’ve done this project’ simply saying ‘everything’ is often a bad sign because not every system is suitable for Virtualisation.

For every platform you decide to Virtualise you need to figure out at least the following things

• Is it supported on a Virtual Platform by the vendor?
• Is the operating system supported on Virtualisation?
• Are there any specific hardware requirements for the system?
• Should we really virtualise everything? (I hate a dislike of virtualising Active Directory)

Resource Mapping

Once you have built your master list of servers and services you wish to Virtualise you need to get a handle on exactly what your systems are doing. I’ve been in the position of placing several different workloads on a single system and then crying as the performance degraded until the services became unavailable.

Before you fall in to that trap you need to monitor your systems for a period of at least 2 weeks if not longer to start gathering the metrics you will need to make your Virtualisation work.

Off of the top of my head you should look at things like

• CPU Usage
• Total Memory
• Memory Usage
• Disk Size & Utilisation
• IOPS
• Backup Windows

For each of these metrics you gather you need to try and map their growth over time so you can figure out how long they’re expected to grow over the course of your Virtualisation System’s life. As a rule of thumb in house we consider a growth rate of 20 to 30% over a 5 year period if we don’t have any metrics to fall back on.

Our initial attempts at Virtualisation fell afoul of performance issues because we tried to do too much with too little and only by having the numbers can you really avoid that issue.

Scoping Hardware

Once you have the metrics and the scope defined you can start thinking about your hardware requirements, and discussing these with the myriad of companies who are willing to supply you with your hardware. Having the hard numbers available means you can purchase a system that you know will work and ensures also that you can purchase a system which isn’t over or under specified for your projected needs.

At the very least for a redundant set up I would suggest some form of shared storage and 2 front end servers for serving the virtualisation, obviously your millage may vary on this depending on the scope of your project and the resources your virtualisation requires.

If you are virtualising a line of legacy systems which are not mission critical then you can lose the shared storage and the second machine and run with a single virtualisation host. If you are planning on running mission critical systems through virtualisation then the absolute minimum is two servers and some form of shared storage for fail over, as the criticality of your systems increase you may even find yourself needing multiple storage systems which are mirroring with each other to mitigate against any form of down time.

Procedures, policies and maintenance

After you get your first Virtual system you will likely find that it takes off like wild fire, everything becomes a candidate for Virtualisation. I say this as the voice of experience.

Your policies and procedures need to act as a kind of gate keeper to ensure that you do not end up migrating systems to a virtual platform which are not designed, supported or even able to run on such a platform.

How or whether you choose to implement these policies is up to you at the end of the day but early in the life cycle of Virtualisation I would seriously suggest you stick with the less critical systems first until you have gotten your feet wet. Virtualising Exchange on your first day will not go well when Exchange stops performing as well as it used too.

It’s okay to say no

One thing I feel I should stress in all of this is that after you’ve put the work in to mapping out your scope and your current systems you should feel 100% able to say do you know what guys, Virtualisation is not the way forward for us.

The point of doing the work up front is to provide due diligence about what exactly you are getting yourselves and by extension your company in too.

Don’t feel pressured by other techies, management or by vendors in to doing something you are not 100% happy supporting for the next 5 years.