Considerations for virtualizing Exchange 2007 mailbox servers

Microsoft Exchange Server hardware virtualization is so popular that it seems as if everyone is moving their entire infrastructure to a virtual server environment. That being the case, I want to discuss some of the issues you may encounter when virtualizing Exchange 2007 mailbox servers.

Microsoft’s virtualization support policy

Microsoft supports virtualizing Exchange Server 2007 on Windows 2008 servers running Hyper-V. However, there are some significant restrictions to the supported hardware configurations. Before planning your Exchange virtualization infrastructure, I strongly recommend reviewing Microsoft’s official Exchange Server hardware virtualization support policy.

Does Exchange Server virtualization make sense?

When the concept of server virtualization was initially introduced, the primary motivation behind it was to make better use of underutilized hardware. Servers that run protocols and services such as Dynamic Host Configuration Protocol (DHCP) or Domain Name System (DNS) will often only use 10% to 20% of their available resources.

Virtualization lets you combine low-demand servers on a single physical machine to better utilize the hardware. Of course the main benefit to virtualization is that it reduces the amount of hardware that an organization has to purchase and maintain.

Keeping the original intent of virtualization in mind, does it make sense to virtualize an Exchange 2007 mailbox server? Virtualization works best for underused servers. To be honest, I’ve never heard of underutilized Exchange 2007 mailbox server hardware. The Mailbox Server role is usually resource-demanding.

Other Exchange mailbox server virtualization planning considerations

Let’s say that you have decided to virtualize your Exchange 2007 mailbox server. Before you start the migration process, there are some additional considerations to take into account, such as disk management.

Disk management for Exchange mailbox servers can be complex, so let’s keep it simple. Microsoft recommends separate disks for the Windows operating system and/or the Exchange Server binaries, the page file, the information store database and the transaction logs. In a virtual server environment, you have the ability to create virtual hard disks at will.

It’s easy to create lots of virtual disks for an Exchange mailbox server without ever considering what impact those virtual hard disks will have on the system.

One common mistake that administrators make is creating all of the virtual hard drives on the same physical volume. This completely defeats Microsoft’s purpose in recommending separate hard disks for various Exchange Server components. If a physical hard disk that contains all of the virtual hard drives were to fail, then so will all of the virtual hard drives.

You will also encounter disk I/O issues with this type of setup. Exchange mailbox servers are very I/O intensive by nature. If you place all virtual hard drives onto a common physical volume, then disk I/O will suffer. Even if that volume happens to reside on a high-speed RAID array, all of the virtual hard drives will be competing for a limited number of I/O cycles.

I’ve seen a few lab deployments get around this problem by using storage area networks (SANs) to host the necessary disk volumes and then use iSCSI to connect the virtual server to the SAN. While this approach works well, there are a couple of caveats.

Although Hyper-V is designed to allow virtual servers to communicate directly with the server hardware, there is one big exception to the rule. All disk I/O is still coordinated through the host operating system. To keep disk I/O from becoming a huge bottleneck, it is important to connect the iSCSI to the SAN through the host operating system, not through the virtual server.

Once the connection to the various LUNs has been made, use the Disk Management Console to flag any volumes that your Exchange server will use as offline. This keeps the volumes from being available to the host operating system.

You must then configure the virtual server to perform a SCSI pass-through. This allows the virtual machine to connect to the SAN volumes as if they were local.

Finally, you must use the virtual Exchange Server’s Disk Management Console to mark the volumes as being online. Exchange can now use the disk volumes even though the virtual server itself has no knowledge of the SAN.