I started writing a comment, but realized I had so much to say that I’d flood his comments field, so I will post my response as a blog post instead. I recommend that you read his post first so you know to what I’m responding.
I’m a bit surprised about this article, as it seems your arguments are very straw man like, meaning you set up a set of perceived arguments for virtualization and then slash them down as if they were _the_ arguments for virtualization.
You say that performance is rarely a reason for virtualization. Granted, virtualization does not increase performance in any way, but it does allow you to balance performance utilization. You may have low-impact servers that are basically utilizing 5-10% of a physical machine, and putting all those onto a single host will save you cost.
This does not only affect SharePoint, but other server roles as well. Perhaps you need a DFS server or a configuration store, or something like that. Put those machines on a single metal box and you’ve utilized a lot more of that physical machine, saving power, money, and maintenance.
So, what about those high-impact servers? Well, you need more metal, but you’d need that in any case. The overhead of modern virtualization is negligible, so virtualizing on a single server still makes sense. For example, what happens when you physical machine no longer meets the performance requirements? You need a new physical machine including the overhead of installing, configuring, and migrating the existing machine to new hardware.
Resilience and Availability
Then you say that resilience is not as cool as people say, because if your host goes down, all your VMs go down. That is only the case if your VM setup is on a single virtual host, and that is hardly ever the case in well-engineered solutions. Of course, if you put all your functionality on a single server, whether that is a VM host or a SharePoint server, then you are screwed if that machine goes down anyway.
Virtualization allows you to spread your eggs on different physical hosts. In fact, as you say, VMWare and other vendors have long provided functionality for moving running VMs from one host to another, without a second of downtime. This allows you to, in real-time, reorganize your SharePoint farm, moving VMs to either lower- or higher-powered hosts as your needs change.
However, what about patching and updating? Having two WFEs even on a single VM, allows you to patch one at a time and maintain solution availability. In fact, for the sake of availability, I’d argue that it is much better to have two virtual WFEs of 2GB than to have a single physical 4 GB WFE.
Other Benefits of Virtualization
You also forget another major reason for virtualization; hardware independence. You may have sufficient hardware to run your SharePoint environment on physical machines now, and then you want to upgrade to SP2010, hitting you with eight times the RAM requirements as you have for MOSS.
How do you upgrade physical machines? You take them down, open them up, put new metal in them, and refire, hoping your new setup still works. If you want to upgrade even more, you’d better hope you have enough RAM slots or that your server supports the new CPU you desperately need. Or you reinstall the whole thing on new physical hardware.
How do you upgrade a virtual machine? You drag-and-drop it from one host to another. Worst case you may need to reboot to tell the VMHost that your VM now needs 32 GBs or RAM. You never need to exchange a CPU or be limited by what the hardware vendor thinks is enough room.
Want to add a new disk? Heck, just a few 10 GB disks to offload the pagefile would be nice, but where to go get physical spindles that are 10 GB these days? And does your metal have room for more disks at all?
You’re getting a SAN, that’s what you do, but then again, a VM can just as easily utilize the same thing so there’s absolutely no benefit to physical machines at all, when it comes to hardware upgrade.
With the excellent comments by Brent Ozar, I’d even recommend that you virtualize your SQL server. Granted if your physical machine is already overloaded then adding virtualization will solve nothing. That is not an argument against virtualization however, it is an argument for better hardware, which in any case, virtual or not, will be the solution.
Brent’s arguments about single HBAs for individual VMs is a good one, but it is only really applicable when you are saturating a full HBA. Disk I/O, memory, or CPU limitations is not a usable argument against virtualization. At that stage, however, when your SQL server actually needs multiple HBAs, then you had better have some good hardware and network people available in any case, and you likely do as well.
So, in Short…
Use virtualization, but before that, use your brain.
Found this article valuable? Want to show your appreciation? Here are some options:
a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.
b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.
c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!