Virtualizing Exchange or SQL Server with VMware? Think twice

Virtualizing resource-intensive applications such as Microsoft Exchange and SQL Server is increasingly possible. But you should understand the licensing and migration implications.

With VMware's vSphere, virtualization administrators will be able to provision much larger amounts of RAM and CPU...

resources for virtual machines (VMs), which should make virtualizing resource-intensive software such as Microsoft Exchange and databases such as Microsoft SQL Server increasingly popular. But even with this resource boost, some organizations may still be reluctant to install Microsoft Exchange and SQL Server on production VMs because of the licensing and migration implications.

Before readers jump to conclusions about where this argument is going, running Microsoft Exchange and SQL Server as virtual machines is of course possible. In fact, VMware provides plenty of resources on virtualizing Exchange 2003. A VMware white paper on virtualizing Exchange 2003, outlines a specific scenario for an Exchange implementation. Another offers a specific configuration and performance data with a workload using the SQL Hammer tool for SQL Server running as a VM. So VMware is fully capable of running these workloads – that is not the question.

While there are too many variables with any segment of virtualization to make a blanket statement about whether you should virtualize Exchange or SQL Server, the issues I want to address here are architecture, costs and licensing. These issues may not apply to all organizations, so as we cover each issue, I'll quantify where caveats apply.

Licensing considerations are paramount

One of the finest qualities any IT professional can showcase is licensing finesse. Envisioning situations and their licensing ramifications is a skill that takes time to develop. SQL Server, Exchange Server and VMware Server licensing are all expensive.

Organizations generally make top-level decisions on which licensing model will be used for SQL Server environments. There are three licensing options for SQL Server: per processor, per server with device client access licenses (CALs), and per server with user CALs. The two CAL-based licensing option for SQL Server work well for organizations that have a mature cost allocation model (one user represents one CAL). The CAL-based models also fit into environments that have SQL Server configurations that will differ by department or how the databases need to be configured (namely security). The issue is that organizations often decide on licensing without considering whether they will SQL will run as a virtual server.

When you decide to virtualize SQL per processor, the good news is that licensing costs are controlled because all databases and all connections are accounted for, so you don't need client connection licenses. (This does not account for the Windows OS, however.) For many midsized or large environments, this will exist as a large system with more CPU, RAM and storage.

The hardware inventory required for a large SQL server may look a lot like a VMware ESX host – that is, how much memory and CPU is assigned to the computer. Storage interfaces such as Fibre Channel host bus adapters (HBAs) may be the same as well. The virtualized SQL server could almost consume the CPU, RAM and storage dedicated to an entire ESX host. The High Availability (HA) requirement for this important VM also increases SQL server's footprint in most VMware Infrastructure 3, and soon to be vSphere, environments.

In addition, it may still be desirable to run Microsoft Clustering Services (MSCS) for application-level availability. This can accommodate operating system topics such as updates, reboots and database service related issues. In this case, you'd need to allocate two virtual hosts in order to properly virtualize SQL. When VMware licensing is rolled into this kind of technology, the cost of providing two dedicated hosts to support SQL increases significantly as features such as HA, Distributed Resource Scheduler and VMotion are also licensed. Using MSCS with a mixed pair of one physical server and one VM is an option, but this architecture hasn't been widely adopted.

A good example that helps depict SQL Server licensing variances stems from a discussion I had with a VMware administrator for a large bank. We discussed what we are doing with VMware virtualization, and when the subject turned to SQL Server, we had completely opposite ideas. The bank's solution was to have a large number of VMs running SQL server with a small number of databases on each SQL instance. The opposite idea is to limit the number of SQL installations to a small number of physical servers with SQL installed. These would have a much larger number of databases on the SQL server instance.

The key difference between the two setups lies in the cost allocation, or determining who manages and who pays for the various databases. From an ongoing management perspective, it made more sense for the bank to separate all of the databases -- making them more clear VM candidates.

Exchange has similar cost considerations that revolve around architecture and licensing. Larger implementations of Exchange Server 2007 Enterprise Edition with a number of storage groups can translate into a configuration where an Exchange VM would be provisioned equivalently to that of an ESX host. Certain roles, however, such as separating the Exchange Hub Transport server role can make good VM candidates.

How VMware virtualizes Exchange

VMware's virtualization practice for Exchange can shed some light on how to virtualize an Exchange server. A report from  outlines VMware's Exchange environment. It indicates that VMware has 7,800 mailboxes across 22 mailbox servers and seven hub transport servers. For many environments, 354 mailboxes per mailbox server is a little light. Licensing can add up quickly as each Exchange Server 2007 Enterprise server has its own cost (list price at $3,999) in addition to the VMware ESX licenses.

The other factor to consider when thinking about running Exchange and/or SQL Server as VMs is that Exchange and SQL have the potential to be very large VMs that can affect migration times because of the involved RAM. While 10 Gigabit Ethernet would speed VM migrations, even with the increased migration speed (at a higher per-port cost), having a large VM may be a burden on the virtualization environment from a migration perspective.

Future considerations

Previously I mentioned that the hardware inventory to build a large SQL or Exchange server on a physical system may be similar to that for a VMware ESX host. It may be a good idea to purchase all large systems with the same hardware inventory so that you can repurpose servers at a later point. For example, if you built VMware ESX hosts as a four-CPU socket system and the SQL Server installed on a physical server would be a four-CPU socket system as well, it would be a good idea to purchase the same model and processor series.

To underscore what I said previously, running Exchange or SQL Server as virtual machines is a possible and supported configuration. If your organization has licensing strategies that align with some of the situations that have been outlined above, you may want to rehash some of the cost calculations to ensure that the overall cost is not higher to run Exchange or SQL as virtual machines instead of physical ones. That is to say, it's not worth running more costly VMs just for the sake of being virtual.


Rick Vanover (MCTS, MCSA) is a systems administrator for Belron US in Columbus, Ohio. Vanover has more than 12 years of IT experience. His areas of interest include virtualization, Windows-based server administration and system hardware.


This was last published in June 2009

Dig Deeper on VMware basics

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.