CPU Over-Commit in Hyper-V running SQL Server

When Hyper-V was first launched there was a lot of fear and uncertainty about running SQL Server on it some inertia around virtualisation of database in general. Now it’s been around for a while production virtualisation is mainstream for small and medium workloads that need up to 4 logical processors.  There’s a lot of guidance on best practice out there and one early piece of guidance was that you shouldn’t over commit processors. Before I get into that we have ..

image

The virtual processor is what you assign to a virtual machine and then shows up as a CPU in your virtual machine. it is roughly equivalent to a core and there are rules on how many logical processors you can assign..

image

 

For example on my shuttle, Binky, I have a single CPU with four cores. so I can assign 4 virtual processors to any VM.  If I assign 4 virtual processors to 2 virtual machines (which you can definitely do) then I am over committing the processing capability I have.  Note this doesn’t apply to RAM i.e. if I have 8Gb RAM I can’t assign more RAM than I have to the sum of running VM’s and the RAM used by the host operating system.

Anyway back to over committing the cores; in early best practice it was recommended that you didn’t do this for VMs running SQL Server and other intensive workloads e.g.SharePoint & Exchange. However I have just found this whitepaper on High Performance SQL Server Workloads on Hyper-V, and this now recommends you don’t over commit by more than 2:1.  There is a graph explaining this in the whitepaper but I found this on a recent TechEd deck which explains a little better..

clip_image002

What you can see here is SQL Server running the TPC-E benchmark. To the right of the graph where over commit occurs there is still near linear performance increase. So how is this possible?

The answer is in the small print at the top of the slide – SLAT on the AMD CPU (EPT in the intel world) and support for this new feature in Windows Server 2008 R2. Essentially this is a way of mapping physical memory to virtual memory to improve performance. The downside is you need the latest generation of CPUs to get this and of course Windows Server 2008 R2, but the benefit is even higher virtual machine density on a given physical server, even running workloads like SQL Server.

So I am still confused as to there is still resistance to virtualisation of SQL Server in general and to Hyper-V in particular, perhaps someone can enlighten me?