Comment My 45 cents.... (Score 5, Informative) 464
You can actually virtualize a whole lot of things. The real key is to put a lot of money into the virtualization hosts. CPUs/cores, ram, a really good storage system.
For the small budget, you can get by on a lot less.
I have virtualized several entire development stacks (app servers, DB servers, storage servers, reporting servers). {But you trade a bit of performance for a reduced physical server count (10 or 15 to 1? A pretty good tradeoff if done right)}
You CAN virtualize SQL servers. Most business DB servers at the small shop end are fairly light load (like finance systems) and virtualize well. {But if performance makes you money (ie: you have a SAAS product - then stay physical }
You CAN virtualize an entire Cognos stack (it is made up of many servers depending on how complex your environment is). {However, IBM is correct that in a heavy BI workload environment deserves physical servers. I run over 18,000 reports a day on my produciton stack. Not going to virtualize that any time soon.}
You CAN virtualize entire profit generating websites. {As long as you keep an eye on host CPU and perceived performance at the end user level}
You can virtualize a lot of this in relatively small environments.
But.. Everyone here who has said it is correct: DISK IO is a major contention point. If you stuff all of your virtual machines inside one single giant data store (VMWare term for a single large disk partition) and expect super fast performance 100% of the time, then you will be greatly disappointed. One of my own stacks would grind to very intollerable performance levels whenever someone restored a database to the virtualized DB server. We moved that DB server virtual machine's disk load onto dedicated drives while leaving the machine itself virtiaulize, and all those problems went away.
Do not virtualize anything thar requires multiple CPUs (cores) to operate efficently. SQL Server is an example fo something that works better with multiple CPUs at its beck and call. In virtualization though, getting all the CPU requests to line up into one availabe window bogs the whole virtual machine down (jsut the VM, not the host). If your workload can't survive on a single virtual CPU, or two at most (single core each), then you are best to keep it on a physical server.
Time sensative systems and high compute workload processes are also ideally to be left out of virtualization. Except.. If you can put a beefy enough box under them, then you might get away with it and not notice a performance impact.
The biggest mistake made when going into virtualization (besides not planning for your DISK IO needs) seems to be over provisioning too many virtual machines on a host. This is a dark trap if you are lucky to have the money to build out a high availability virtualization cluster. You spread you load across your nodes in the cluster. Then one day one goes off line and that workload moves to another node. If you only have two nodes, and one is already over subscribed, suddenly the surviving node is way over its head and everything suffers until you get in and start throttling non esscential workloads down.
So, what do you not virtualize? Anything where performance is critical to its acceptance and succcess. Anything that a performance drop can cost you money or customers. (Remember that internal users are also customers).
Plan ahead ALOT. If you feel like your not going in the right direction, pay for a consultant to come in and help design the solution Even if it is only for a few hours. (No. I am not a consultant. Not for hire.)