YSLGuru (7/26/2012)
..."What does it mean that "only the OS would be on the VM and the database files would be on local drives"?
Its my understanding that the Windows OS will run inside a VMware session (or whatever its called) which means that any application installed will also run within that same VM. I'm told that this VM session is the only one that will run on the host server (the new server we're getting) and so the VM session will get %100 of the resources as opposed to sharing with other VM sessions. The OS drive is C. The other drives are locally attached RAID drives (as opposed to SAN based which is how the current server is setup).
I fought against moving to the use of VMware or anything else virtualized because I had read about issues with high load RDBMS on VM solutions even when the VM is properly configured for use with SQL Server. Originally the plan was to do everything within VMware and use SANs based drives. Using Red-Gates SQL Monitor I was able to show why this was a very bad idea since our current I/O is terrible because of our SANS setup which needs updating/replacing. The Avg Read/Write times are just awful but until I had something to show as proof (i.e. SQL Monitors stats/metrics it captures and stores for reporting purposes) I couldn’t make the case for moving off the SANS.
Ok, I understand what you're describing.
If the VM host is ONLY going to host 1 VM EVER, then what is the value added by vmware? It's not free, and does introduce some (slight) overhead so it needs to be justified to be thrown into the mix. What is their justification?
Of course, if I was a shady sysadmin, I could say it would be dedicated to sql server, then later sneak some additional VM's onto it. That pesky DBA would never notice his server slowing down one day, and if he did complain, I could move the extra VM's off....