help-browser-2Earlier this week I received a great question from a friend, and read something like this.

Hi David,
I usually recommend people to install SQL Server on VM and I argument it by saying that it would make any future hardware migration easier.
However, I just think if company purchases new hardware and going for SQL 2014 they won’t upgrade their hardware for at least 5-6 years. At this time there will be a necessity to go to the fresh version of SQL. So, my argument does not work anymore.
Even with very low overhead, VM adds more complexity to SQL Server environment, by adding “moving” pieces which can break.
How would you justify a case of having VM when client plans to have a model “one machine – one SQL Server”?

That’s a wonderful question, and I get asked this all the time.

I can justify the desire for virtualization in the scenario you described. There are a number of reasons to consider virtualization given those constraints.

number-1-iconHardware independence is still a great reason to virtualize, especially for disaster recovery purposes. Simply having the ability to replicate the VM itself to another datacenter and be able to restart the VM without requiring the exact same hardware underneath is very beneficial. It simplifies DR to an (almost) trivial task. You can also use last generation hardware (or even a public cloud unlimited web hosting) for your DR site infrastructure, and it will work beautifully!

number-2-iconRisk minimization for high availability is huge as well. If that physical server were to fail, you’re at the mercy of whatever support policy you have with your hardware vendor, which can take hours or even days. Even if you are using SQL Server HA, you now have a situation where you could now be presented with a single point of failure. With virtualization and the right datacenter architecture, in the event of host hardware failure, that VM is down for about four minutes, give or take, while it restarts on a remaining host. That fact alone is why I say virtualize without hesitation, even if you’re leveraging physical clustering or AGs for robust SQL Server-level high availability.

number-3-iconHardware portability still plays well. Even if you plan for 5-6y from the physical server, how fast are the database demands on the hardware growing? Will you outgrow that physical server before then? What if you need more RAM four years from now and it’s cheaper to buy a new server with more RAM than simply upgrade your current server? The same goes for CPU cores, clock speed, etc.

face-coolEven with virtualization’s low overhead, it IS another layer in the infrastructure. But, managed correctly, I claim that the benefits described above outweigh the added layer drawbacks, as long as the admins in your environment are comfortable managing large and resource intensive VMs. Virtualize everything!