Physical vs virtual performance

[arjanr]

I have a server with dual 8-core CPU's with HT. This server will be part of a SQL AlwaysOn availability group. I can either install SQL Server directly on this machine so it can use all 16 cores (32 threads) or I can install ESXi 5 on it and deploy a 32 vCPU VM on it (it will be the only VM on this machine). The reason for using a VM is that the server might not require all resources and if I deploy it as a VM I can scale back the number of vCPU's and host other VM's on this machine. Would the performance of SQL server be much different whether I deploy it straight on the physical server or as a 32 vCPU VM? The underlying hardware is the same in both situations, the only difference is that with a VM I have the hypervisor layer between SQL server and the hardware.

[Davoud Teimouri]

If you have right sized environment and you don't have any bottleneck, VM will run with same performance.

Performance on virtual environment is different with physical environment. You have to consider about many metrics such as CPU ready to achieve best performance.

If your current SQL server doesn't have high workload , you can replace that with another virtual SQL server.

Please check this out: http://www.vmware.com/files/pdf/solutions/SQL_Server_on_VMware-Best_Practices_Guide.pdf

[Cyberfed27]

The less politically correct answer is yes your VM will most likely not perform as well as the physical machine. Why? Well as Davoud posted you may have a bottleneck between your physical hardware/storage and VMware. Plus other VM's will be using resources from the hosts. Is it possible to achieve the same performance in a VM as in a physical box? Sure if everything is built correctly. Most modern servers are so powerful that they usually have resources idle, like you said you aren't sure what your VM workload will be.

I vote you try it, start with the least amount of resources you need to run and scale up as needed. Having your server in a VM provides you a much easier way of doing a restore in the event of a OS failure or hardware failure. It makes disaster recovery much easier than if dealing with a physical server that dies on you. That alone is good enough reason to tackle any small performance hit you might experience by going to a VM.

[JPM300]

Hey Arjanr,

We recently did some testing on this and ran Dells Benchmark Factory on a SQL server to get a good baseline with all of the industry standard SQL tests.  We then P2V'ed this same system onto the exact same host that it was previously running on then ran the Test again.  So the SQL VM was running on the same host but that physical server was just running ESXi5.5 now.  We noticed about a 10% drop in performence between all the test but it was very marginal.  We also noticed that anything after 8vCPU didn't really get that much performance at all.  The host was a dual socket 8 core server.  So we dropped the VM to 8vCPU and set the memory to whatever we needed.  We have ran a BUNCH of development testing at the system and it has passed with flying colors thus far, but it woudln't hurt to do some baselines on your physical hardware first, then try a test p2v, run some baselines and compare.  If the margin is small enough you will feel comfortable enough to move forward, if it is not, you might have to look at what is casuing the bottle neck.

Typically with SQL as a VM it is a better idea to scale out with multiple VM's instead of scaling up, but that's not to say scaling up is impossible, its just usally really expensive.