August 29, 2011

Not quite a year ago, I wrote about our use of virtualization here in OurVirtualizationUse. That entry is now what we call 'inoperable', because we have just finished de-virtualizing; reverting back from virtual machines to running those machines directly on real hardware. We did this ultimately because we think that it's less of a hassle to run machines on real hardware than virtualized.

In retrospect, I think that part of the problem is that our virtual host machine was underconfigured in terms of RAM and disk space. It had what seemed like a decent amount of both, but virtual machines add up surprisingly fast (especially once you start worrying about backups of them and so on). And certainly it's a factor that we have plenty of spare hardware that's large enough to easily run stuff on, even a single Windows server.

But a significant issue was that managing the host environment was a hassle and managing the virtual machines on top of the host environment was another hassle. Because we only had one host machine, doing any significant maintenance on the host machine meant taking down all virtual machines and then starting them again. And while making the host machine an Ubuntu LTS server was useful because we already had a bunch of infrastructure for managing those, it meant that we did have to manage it and in particular we had to apply kernel updates. Every kernel update was a hassle, and it didn't help that we were using a third-party virtualization system that needed special magic hand-holding after a kernel update. Even beyond the host updates, managing the virtual machines always took remembering the special steps needed to do things get 'console' access to them and force power cycle them. The whole experience was just annoying.

In the end, the person who built the next generation of our Windows terminal server decided that he would rather build it on real hardware, partly because it would be less of a hassle and partly so that he could easily give it a lot of disk space and memory; that decommissioned two of our three virtual machines. Keeping a virtual host machine running just to host a single virtual machine that forwards some low-priority email seemed, well, kind of stupid.

(I'm thinking of this because today was the migration from the old virtualized Windows terminal servers to the new non-virtualized one. Normally we might keep the old virtualization server running in the corner just in case, but there's an overnight building wide power shutdown tonight so we powered it off along with everything else and we don't plan to turn it back on.)

I definitely don't think that this makes virtualization a bad idea in general. It didn't work out for us, but I think it would in a different sort of environment and certainly it works for other people. (I have some thoughts on what sort of environment it would probably work well in, but that's for another entry.)

Comments on this page:

From at 2011-08-30 02:33:27:

running production on a virtual environemnent requires using a cluster of virtualization hosts. You have just learned that. You need at the very least two hosts and one centralized storage array where the vm's live. That way you can turn one of the hosts for maintanance and the vm's keep running.

It's just common sense.

From at 2011-08-30 10:09:52:

There is no real benefit to virtualization unless you have a cluster, shared storage, and live migration. Live migration is a "killer feature."

I also find that virtualization works best for light to mildly loaded systems. In your environment I probably would not virtualize an rdp server. However, in my shop of 12 people, everything is virtualized.

Written on 29 August 2011.
« Designing services for disengagement
Who is the audience for a trouble ticket update? »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Aug 29 22:55:22 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.