Tech —

Virtualization: let’s talk about your mistakes

We all make mistakes, especially when rolling out new technologies. This is as …

One of the pleasures of reading the The Server Room is taking part in various threads on the theme of "lessons learned." So when we hit upon the idea of distilling the collective wisdom of the Ars forums into an article on virtualization for a broader audience, the first thing we thought of was, "let's ask everyone to share their biggest virtualization deployment mistakes." The results so far are worth checking out for anyone who's about to make the jump to a virtualized server room.

I'll summarize just one of the issues highlighted so far, to give you a sense of the discussion.

VM sprawl

One of the sub-discussions going on in the thread is about VM sprawl. Specifically, this is one instance in which the low up-front cost of deploying a new VM can actually drive up overall TCO in the long-run. Since the amount of technical and administrative overhead involved in creating a new VM is so low, users think they can ask for lots of them. User neilhwatson summarizes the problem that a number of users said they could related to:

Vms become cheap and easy to setup. Suddenly an organization has far more hosts than they ever would have had had they been using only physical hosts. 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.

The key is apparently to have in place two things, the first of which is an approval process that's robust enough to keep unneeded VMs from getting deployed. Reader Accs says, "To keep the VM growth under control, you need a process that verifies that the need is real. You also need to verify that the need continues." Murph182 adds:

Just as you (hopefully) don't stand up a new physical box simply because Joe in Accounting says "hey, we need a server for X" without going through some kind of approval process, you don't create a new VM without going through a similar process. On the flip side, because you do have the flexibility inherent in a virtual environment, you can be more liberal in your approvals because you can easily remove or archive the VM when it is no longer needed...as long as you have a process in place to ensure that you actually DO it.

The second thing you need is good admin tools that let you do lifecycle management, so that you can manage VM growth and identify and close down unused VMs. Accs also emphasizes that it's critical to have tools in place to do this from the start, instead of beginning a virtualization deployment by using people to track things, and then thinking that you can just shift to tools later. "With current IT workloads, the conversion from people to tools often doesn't get to the top of the list before a new pile of work gets dumped... If you have the management tools in place, VM sprawl can be managed and controlled. If not, there's no time to get them set up, and you're toast."

If you have virtualization lessons and/or war stories to tell, drop by the discussion thread and share your insights. At some point, we'll be distilling the whole thread into a large "Things to look out for when starting a virtualization project" article, so the more contributions we have, the more ground we can cover.