Is SQL Server Virtualisation Really Possible?

Businessman clicking SQL on a virtual screenSQL Server virtualisation is rapidly on the rise, with benefits including countless options and cost savings among others. However, plenty of organisations remain unconvinced on the idea of an SQL Server operating in a VM or virtual machine.

Hence the question: could a virtual machine really house and run an SQL Server? The answer – yes definitely, but also no. You see, there are significant advantages for SQL Server virtualisation, such that you could effortlessly build high-availability databases without having to deal with the expense and complexity of Windows Clustering.

This means that your server would likewise be ready for technologies that are virtualisation-based. It would also come in handy when your organisation’s SQL Server sprawl becomes difficult to manage.

Boosting server performance

Additionally, with a well-developed infrastructure, you could easily boost server performance by simply moving a busy server virtual machine to one that provides more capacity.

If you require another processor, you could simply disable the virtual machine and just add a virtual PROC, and then enable it again. However, could virtualisation really handle your SQL Server? In the past years, the answer would have been yes, but barely, answers an experienced SQL DBA provider.

These days however, hypervisors are not only up to par with SQL Servers, but likewise operate with hardware developed for virtualisation. All server-class and latest processors have built-in virtualisation extensions, which allow them to run SQL Servers inside VMs.

In addition, server memory is immensely affordable these days.

Some caveats

You must tread carefully though. For instance, memory overcommit abilities allow a host of SQL Server virtualisation to meet its need for memory when it’s busy and then reallocate the physical memory dynamically to another VM when the server is in idle mode.

Obtaining access to many different processors is likewise crucial. To combat this, you need to choose which databases to virtualise.

For instance, you could opt to virtualise instances related to SQL Server sprawl, such as say one that was just installed solely for supporting an insignificant archival-log app, or an Express instance that only runs someone else’s project database.

Databases like these do not really require a decked-out infrastructure and could function perfectly inside a VM.

Yes, it is possible to virtualise your SQL Server. Start with databases that do not need too many resources, workload-wise, and go from there. Test and consistently monitor results as you go in order that you could determine which server machines you could virtualise.