Jonathan Kehayias (1/11/2009)
One other thing to test for your larger database is the effect of parallelism waits CXPACKET on performance. My experience with VM's is that parallel processing is a performance killer rather than a performance enhancer. The reason for this is that the VM host software is configured to manage context switching and the multiple threads are no longer going against multiple processors necessarily. Generally speaking, I see much better performance from my VM's be setting the Max Degree of Parallelism to 1. If your 1TB+ database currently benefits from parallel processing, you definitely want to test what the performance will be like under a VM.
I absolutely agree with this. Our Windows administrators thought the VM DR advantages were worth VM'ing one physical machine as one large VM machine. This was a server with several 100+ GB data marts and lots of parallel query plans. Performance was 25% to 400% slower in the VM world compared to the pure physical. Obviously your milage may vary, but bottom line is you should really test VM versus physical before you decide.
Having said that, SQL Server on VM works great for us in other areas. Generally these are smaller home grown or third party apps. Like one of the earlier posters, we find that many 3rd party apps assume that they are the only user of the DB server and expect sa user and xp_cmdshell. I'd like to say don't buy it if the vendor doesn't know how to code it responsibly, but I don't get to make all of those decisions, so we just VM it.