Demystifying SQL Server Virtualization

Because SQL Server can be I/O intensive, it hasn’t been at the top of the list of server types you’d want to virtualize. However, with the recent release of Microsoft’s Hyper-V and VMware’s new ESX Server 3.5, SQL Server virtualization is becoming increasingly interesting. Performance for many deployments is proving to be perfectly acceptable, especially in light of the benefits virtualization can offer—such as increased hardware utilization. One remaining concern about SQL Server virtualization is that confusion has grown around virtualization itself. I want to clear up some of that confusion.

First, some people think that the expression “virtualizing SQL Server” implies that you have to do something to SQL Server to make it run in a virtual environment. That’s not the case. From a management and implementation standpoint, there’s absolutely no difference between SQL Server running in a virtual machine (VM) or SQL Server running on a physical box. To learn more about virtualizing SQL Server, see “Virtualizing SQL Server,” May 2007, InstantDoc ID 95349.

Next, confusion arises around the difference between named instances (a SQL Server feature that is not widely understood) and virtualization. Named instances allow you to run multiple copies (or instances) of the SQL Server database engine simultaneously on the same server. You typically find named instances in hosting environments. Named instances share the same server and OS and provide better performance than virtualized servers because they run directly on the physical server. SQL Server virtualization enables different virtualized SQL Server instances to run with different hardware and OS configurations and provides more flexibility for recovery because the VM containing SQL Server is insulated from the underlying hardware platform. However, because SQL Server in a VM runs on virtual hardware, the performance doesn’t match the performance that named instances can achieve running on physical hardware.

One source of confusion is that there are three different types of virtualization, and not all virtualization platforms are created equal. Hosted virtualization products, such as Microsoft Virtual Server 2005 and VMware Server, work by running virtualization software on top of a host OS. A new generation of hypervisor-based virtualization platforms provides a small special-purpose layer of software, called the hypervisor, that runs directly on the hardware, isolating VMs from the underlying OS. By running directly on the hardware, a hypervisor provides better performance, reliability, and security than hosted virtualization solutions. Examples of hypervisor-based virtualization are VMware ESX, Microsoft Hyper-V, and Citrix XENServer.

A third, less well-known type of virtualization product uses OS-level virtualization. With OS-level virtualization, it’s the OS that’s virtualized instead of the hardware level. OS-level virtualization offers performance and hardware utilization benefits just as hypervisor-based virtualization does, but its ties to the underlying OS makes it less flexible than both hosted and hypervisor-based virtualization products. OS-level virtualization has the advantage of low overhead, but it also requires each virtual OS (or container) to be the same and the hardware configuration for each container to be the same. Parallels Virtuozzo Containers is an example of an OSlevel virtualization solution.

I hope I’ve addressed some of the common questions and misconceptions that surround SQL Server and virtualization. Once you understand the available virtualization options for SQL Server, you can start to examine where they might fit into your environment. If you have questions about virtualizing SQL Server or have a story to tell about your company’s move to SQL Server virtualization, send us an email at letters@sqlmag.com or visit our SQL Server forums.