In spite of the fact that virtualization has officially been hot for well over two years, it's still fairly new to many businesses. Indeed, if the number and regularity of threads in the Ars forums discussing first-time virtualization deployments is any indication, there are plenty of businesses in categories ranging from SMB all the way up to the enterprise that are still just getting started with virtualization. And again, if the Ars forums are any indication, many first-time virtualization deployers are learning many of the same lessons. So wouldn't it be great, we thought, if we could distill the collective wisdom of regulars in The Server Room, our forum dedicated to servers and datacenters, into an article that could help others avoid common pitfalls and blunders in virtualization deployments?

To this end, we started a thread entitled, "Biggest mistake you (or someone else) has made in a virtualization deployment?" We had quite a few responses, many of which centered around a common set of basic themes. This article boils down that discussion into a set of six steps that everyone considering a virtualization deployment should follow if they want to avoid the most common pitfalls.

Step 1: Make sure virtualization is right for you

Not everybody needs to run out and virtualize just because it's the thing to do. So before sinking money and effort into going down the virtualized server path, be 100 percent sure you know all of the reasons why it's a good fit for your business.

User Zeebee writes:

You virtualize to consolidate hardware, to potentially lower costs, and for resiliency and for disaster recovery... Some people, unfortunately, try to follow trends for the sake of keeping current, rather than actually looking at what they need.

If you're jumping on the virtualization bandwagon just to jump on it, then odds are higher that you don't have a real plan, or even the right overall approach, and you're therefore more likely to fall into some of the pitfalls below and actually end up with your datacenter in worse shape than if you had just left it alone.

Step 2: Start with the understanding that virtualization isn't a "project," but a new way of doing things from here on

More than one user stressed that a virtualization deployment is not an "IT project," with a fixed time horizon, budget, final deliverables, and so on. Rather, a virtualization rollout marks the beginning of a fundamental shift in how your datacenter operates.

murph182 went into some detail on this point, and his detailed case for this enterprise-wide mindset shift is worth reading in full:

Much like you have to make a lifestyle change instead of simply "going on a diet" if you want to lose weight and keep it off, you can't just "implement virtualization." It's a completely new way of doing things, and it's the way you're going to be doing things for some time to come. Yeah, there are stages to things but the overall effort doesn't end, it just becomes the norm. When it's treated as a project instead of simply being the reality of your datacenter, [then] you don't get full integration with all facets of your IT operation. Other groups in your IT structure (storage, network management, etc) treat you as someone to provide resources to rather than as something to integrate their processes with. Management treats it like any other project, to give or remove resources as they see fit. And IT in general will treat it as something to pay attention to NOW, and then forget about as they move on to other projects. If, instead, you implement virtualization as a way of life then you get greater buy-in from the various components of your IT organization. The decision to implement better processes in all IT areas to support virtualization becomes easier, and the purchase of the appropriate tools to monitor and manage the environment becomes more likely.

One of the concrete effects of this mindset shift is that you'll start to think about individual server instances differently, because every software component of a server build has to be evaluated in light of the fact that it will be replicated many times across your infrastructure.

User rogerd writes:

Think, for example, about a daemon that wakes up once an hour to check on something (it doesn't matter what...). Once an hour's not much, right? Except you have 100 guests, so that's once every 36 seconds, on average. Still sound like a lightweight process? Still need to be in your standard build? Likewise a daemon that eats 100 MB of RAM, or blindly installing packages because you "might need to use gcc some time." Yeah, maybe you might. Is it worth the storage you just ate?

Ultimately, much of the advice in this article really boils down to a mindset shift, and many of the pitfalls outlined below stem from IT departments and other stakeholders who are simply thinking about virtualized resources in the wrong way.

Step 3: Find the right people, make sure they have thorough, product-specific training. (But don't train anybody and everybody.)

A number of users stressed the damage that uninformed and/or untrained people, both inside and outside your IT department, can have on a virtualization deployment. So it pays to ensure that the people directly involved in the project aren't just enthusiastic bandwagon jumpers who want in on a hot datacenter trend, but that they're really well-trained on the specifics of the products that you're using. Otherwise, promises get made that can't be delivered on.

And on the flip side, one user takes things a step further and advocates that you don't train non-admin stakeholders at all, on the theory that a little virtualization knowledge will just make key decision-makers dangerous.

murph182 warns:

In my experience there simply is NO happy medium when it comes to training people on virtualization topics. Admins need to really know what they're doing or they [screw] things up or, worse, give out information that is completely and utterly wrong... [And for] anyone who is not a designated admin on your virtualization platform, don't bother training them at all. In fact, if you can get away with it don't tell them that a server is a VM... I've gotten screwed more times than I can count by people making decisions based on their flawed understanding of how things work, and then having to completely redesign a project to reflect reality. I really believe that these management-level decision makers think that they understand it enough to not involve me in the decision making process, and it's just caused nothing but trouble. The ones who don't know [anything] get me involved far earlier and those projects tend to go a lot more smoothly. So make sure that the people involved in the project have as much training as they need or just keep them out of things entirely.

Step 4: Put policies in place to prevent VM sprawl

One of the most commonly cited virtualization pitfalls in the forum discussion was the problem of VM sprawl, wherein the number of virtual machines balloons unnecessarily, taxing both compute and human resources. User neilhwatson writes, "With this population explosion comes the over head of administration. Most organizations do not use sophisticated configuration management services resulting in a time deficit and neglected hosts."