Explaining the Proposal: Virtualization Software

In The Proposal, we specified that our server would run VMware's ESXi, and the actual servers that run the actual software would run as virtual machines (VMs or guests - I will use the terms interchangeably throughout the site) within ESXi. So why did we choose virtualization - and having chosen it, why ESXi rather than other virtualization products?

Why Virtualize?

There's a lot of hype around virtualization. You could type the above question in Google and spend hours reading. But quite a lot of that is sales and pundit hype. We're system administrators; we care about what works easily and well. So I'm going to list some of my own favorite reasons to virtualize, in no particular order:

• Stretches hardware further. I've personally done perfmon studies in large and small server rooms. I can't share the data with you (it belongs to the companies I was working for, sorry) but I've seen hundreds of systems idling away with an average of 5-20% disk and CPU utilization - and that's averaged out over days or weeks. Simply put, most servers are over-spec'd for the jobs we give them. But still they toil away, costing money in the form of electric bills (both for the server itself and the HVAC equipment to cool it), support contracts, administration costs, and more. Virtualization very often allows us to take 4 or more of those idling systems and consolidate them into one hardware system - with no perceivable loss in application performance. Anything that lets me use 1/4 the hardware to perform the same amount of work is a great bonus! 
• Makes remote admin easier. I've been in datacenters where literally hundreds of thousands of dollars were spent on KVM systems alone. Fancy KVM systems to be sure: they allowed administrators to control the servers from anywhere they could get an internet connection. But with virtualization, we can do away with the KVM system and still have the same level of control over every guest OS - right down to changing bios options - from anywhere we can get a network connection.
• Normalizes hardware. Server operating systems are tied to the hardware platform they run on. If you restore a system that had an Adaptec RAID controller to one with an LSI (or whatever) RAID card, you are sure to encounter some hair-rending moments getting that system to boot cleanly. With virtualization, you get to bypass all that hassle. The guest OS always 'sees' the virtual hardware presented to it by the parent hypervisor, no matter what the underlying hardware is. Now we can deal with hardware once - at the hypervisor level - and have multiple guest systems within that environment, all thinking they have the same standardized hardware. This provides a great deal of freedom in daily operations!
• Flexibility. Because of the normalized hardware mentioned above, we can easily move guest systems around. Closing a location? Without virtualization you would have to ship the servers to their new locations. With virtualization, you can put any virtualization-compatible hardware at the new location, and literally send the guest server itself as a file transferred on the wire. This is also true within an existing datacenter - need to upgrade hardware? It's easy to simply move your guests to the new hardware. Or to move guest VMs around as your workload changes.
• Less visits to the server room. Now I wouldn't say I was lazy - but I do believe they gave me this nice cushy chair so I could use it! Furthermore, I believe a server room with lots of human traffic is likely a server room with lots of unhappy users somewhere. Humans (me included) break stuff - we spill coffee, pull the wrong plug, push the wrong button. For all of the reasons in the preceding bullet points, virtualization means I can leave my server room dark and cold, full of happily humming systems, the way it was meant to be. 

Now, virtualization is not the solution to every problem - you'll very likely run into systems for which there are good reasons not to use it - but it does, in quite a lot of situations, very handily save money, make you more efficient at your job, and give you options you never had before. I'll take two, please!

Why ESXi?

Let me just list the virtualization products I am aware of:

• Vmware - Server, Workstation, Player, ESX, ESXi
• Microsoft - Hyper-V and Virtual PC
• Xen
• KVM
• Virtuozzo (apparently they changed the name to Parallels when I was not looking)
• Sun Containers / Zones
• QEMU
• OpenVZ
• VirtualBox
• Bochs

... there are many more. These are just the ones I've actually heard of, or used in some small way.

Honestly, I have more experience with VMware's virtualization products than any of the others out there. That may sound like snobbery, but in practical terms, experience matters. When you know your tools well, you can use them more efficiently and do a better job. But even so, as we were embarking on this ITcookbook project, I agonized quite a bit over the choice of virtualization software.

For me, it really came down to two virtualization platforms: MS Hyper-V, or VMWare's ESXi. I simply dismissed all the others. To be (once again) honest, the main reason for dismissing them was my lack of experience with either the products or the companies than make them. VMware is the leader in the virtualization field, and I have a lot of experience with Microsoft products (and I've been seeing some great reviews of Hyper-V).

So I drew up a list of the features I needed, with notes about how each product meets those needs. Then I chose a winner for each feature need, if I could. As best I can recall, it looked a bit like this:

The green boxes are the effective "winners" for each of the listed concerns. Two lines, cost and 'Vmotion' have no green box because the effective answer is a tie.

Another thing I considered (though have not listed above) was that Hyper-V's management products are part of Microsoft's System Center suite, which would provide an attractive, homogenous  management package for most of the network. But in the end, the thing that stands out - and made ESXi the winner - is VMware's longer experience in the virtualization worlds, which translates into a much larger pool of knowledge (both my own, and from other sources) to draw upon. 

Astute readers will have noticed that the reasons listed here have more to do with the real world me (ITchef) than with the FictionalBiz/Bob Bossman scenario we've constructed here. Sorry about that - but it's likely to happen again. And anyway, all of the same concerns could very easily arise from the FictionalBiz or any other workplace scenario. Out here in the real world, ITcookbook is financed from our own wallets, hasn't yet found any sponsorships, and so constructs these scenarios as cheaply as possible!

I have not gone to the effort for drawing up a detailed cost comparison, as I would in more professional scenarios, for two reasons: first, if it costs anything at all, it's out of scope for this project. And second, I know that if later down the road we do decide to migrate to Hyper-V, we can do it with available tools. So predicting possible future costs is a task I can leave in the future. I did find this cost comparison, though, which shows that (for the scenario considered), Hyper-V is the lower-cost solution for managed virtualization - where managed means there is a suite of tools available for moving VMs from host to host, backing them up, managing their resource allocation, etc. All capabilities which are moot at this stage of the project, constrained as it is to one host with no shared storage.