Several years ago, 37 signals wrote a post showing that moving away from virtualization improved response times.
http://37signals.com/svn/posts/1819-basecamp-now-with-more-v...
http://37signals.com/svn/posts/1819-basecamp-now-with-more-v...
I think there are certainly specific web and db loads that aren't going to work as well under VM scenarios, but on the whole our experience has been positive. There will, I imagine, always be a slight 'slowdown' due to VM but with the gigantic push toward 'the cloud' right now, it seems to me one of the last things on the minds of most (and obviously Xen is highly used in that field, which is also what we use).
The bigger question I think is if you are using a highly CPU bound task which VM isn't always very good at. According to Etsy they are very CPU bound, so it makes some amount of sense.
I think most shops with a high hardware need would probably have a mix -- things that scale well to the hardware (eg: database servers) might be set up as clusters of physical machines.
Less (performance) critical stuff like mail servers, bug tracking and time sheet appliances, backup domain controllers etc -- might be run as vms.
I agree that if you find yourself running a single vm on a physical box, you should probably reconsider how you are doing things...
Then again, all things considered -- if your (presumably) easy-to-mange vm based setup gives you enough performance -- why not keep it.
If nothing else as you upgrade hardware, if your workload doesn't increase exponentially, you will be able to consolidate on fewer servers. Consider a database service that in 2003 was set up master-slave on two physical pizza boxes. That could probably be run from two vms (on physically different boxes, for redundancy) -- with capacity to spare on either box today.
Now, if you have 10 legacy apps on old P4 xeons and want to lump them all onto a sandy bridge server and save a bunch of power and rackspace, then separate VMs on one machine makes sense.
Basically, a cluster of 30 servers, all running exactly one VM doing the same thing is on-its-face silly. Why even have the VM then?
The Cloud(tm) excels at addressing some of these. You don't have to pay /as/ highly for staff to manage you machines and network (the provider does much of that for you). You can run smaller, cheaper instances much closer to their limits.
The downside is that you pay a premium to the provider (even if you are your own provider). Additionally you lose a great deal of opportunity cost. If you use the "excess" capacity on the weekend for hadoop jobs, and need to stop them because you have a large burst of traffic, you've hurt yourself. Your non-production hadoop jobs can also have unexpected and unintended impact on your production web servers, causing your users pain.
Given these things, if you focus is on keeping the best experience for users then you should split things apart.
The actual gain you get from cramming as much as you can onto one piece of hardware is much, much lower than you might expect. It ends up being easier just to get more hardware and dedicate that hardware for specific tasks.
- Avleen Vig, Staff Operations Engineer, Etsy
VMs shine when you're stuck with proprietary software that can't all be ported to run on the same kernel, then what you're paying for is a compatibility shim that's cheaper than another box. I don't see much sense for software you wrote in-house.