Woodster, I agree with most of your summary but some of the thoughts need futher addressing. One main is to keep in mind that you shouldnt treat or think of your virtual environment when it comes to planning or maintenance any differently than a Physicaly bound node. Its a common mistake to think that "Hey this is virtual lets just spin up a bunch of boxes and see what happens" Proper planning needs to be done here just like you would (or i hope a company would) if they were properly architecting a physical environment. SQL IS supported in a Virtual environment but even though this is true it doesnt make it right and thank you for highlighting this fact. One other thing worth mentioning is that if your a Microsoft Shop and want to manage your environments on a large scale... meaning as you explained it moving boxes onto different physical nodes.. you better have a decent tool to manage this. SCVMM handles this very nicely and you can even have it distribute the load evenly across servers that are being underutilized. Good post Woodman Bob Fox

I agree. I wasn't trying to make this a super technical article. (That's why I pointed them to the MCS UK series.) This was more to get people thinking, rather than just jumping on the bandwagon. Thinking about whether virtualization was appropriate as one factor in their planning, and if so, how?

I think you fail to understand the value of virtualization in the enterprise. Virtualization assists in provisioning systems, in DR (replication of VM is trivial than other approaches), with Backup (snapshoting the whole VM) and hardware utilizations such as Day/Night processing cycles (E.g. Physical hardware used for Sharepoint during day, ETL during night). It also permits scaling out at short notice with features like moving the VM to new hardware (whilst it is still running!). And regarding hardware resilience, I'd say any serious virtualization environments should be running against SAN storage, perhaps in a blade configuration on hardware with multiple levels of redundancy. Just my thoughts...

Sherod, Again, my point isn't that virtualization is bad. I also pointed out that "virtualized environments also allow for new ways of handling resilience and recovery as well." But, if we're honest, that isn't what is on top of most people's minds. The point is that if you are going to virtualize SharePoint, they *have to be* on your mind.

Woody: Rarely have I read anything about virtualization (or SharePoint server planning in general) that is as rational as your post here. It's great the way you talk it through with real English words. (I'm serious.) The "new hammer syndrome" is always a problem (right now I seem to want to do everything with Web Services and jQuery because I'm working with them) and I've seen too many clients think that buying lots of expensive hardware or virtualizing things was going to make up for their lack of knowledge of what that hardware actually was going to be doing and how to monitor it. (The monitoring tools are only tools, after all: you need to understand what they are telling you.) M.

Great article Woody! While it can work great for utility or legacy systems, extra care needs to be made when planning the move for a high I/O application like SharePoint.

Thanks Marc and Mike!

Do you have experience with the different virtualization stacks out there (Hyper V, VMware, etc)? How much overhead is each one actually creating?

Brian, If you are talking about benchmarks, no, I don't have direct comparisons. The point above is that if you are going to virtualize, you need to make sure that (whatever your stack) you take the overhead into account. Not just the overhead of the stack, but the overhead of any hardware sharing that is to be done. Virtualizing a server that is nearly idle is a very different prospect than virtualizing one that is CPU bound.

Woody, I don't agree with your arguments, but rather than flood your comments with a long post, I've written a blog post to explain my point of view: http://furuknap.blogspot.com/2009/11/sharepoint-virtualization-response-to.html .b