Virtualizing Exchange 2007 and Exchange 2003 with Hyper-V

For a long time I chose not to use virtualization technology in my Microsoft Exchange Server environment because I didn't want to add an extra layer of abstraction to the mix. Plus, I knew that my servers would perform better on dedicated hardware.

Over the past couple of years, though, virtualization technology has improved tremendously. Thanks to Microsoft Hyper-V, virtual machines can directly access most of a server's hardware rather than having to channel requests through the host OS as was previously required. Because Hyper-V offers better performance than Microsoft's previous virtualization products, I have virtualized my own Exchange servers and have assisted some of my clients in doing the same.

Should You Virtualize?
Microsoft supports virtualization in Exchange Server 2007 and Exchange Server 2003 but not earlier versions. Virtualization is mainly used in production environments to make better use of existing hardware. For example, DNS, DHCP, and file servers use very little of the available memory and CPU resources. By virtualizing these types of servers, you can use a single physical machine to host multiple virtual machines. In doing so, the hardware is being better utilized and fewer resources go to waste.

Virtualization typically isn't well suited for servers that use a lot of CPU or disk resources. Unfortunately, in many cases, Exchange falls in this category. If you're thinking about virtualizing an existing Exchange server, it's important that you do some performance benchmarking to find out how much of the server's resources are being consumed during peak periods of activity.

Virtualization adds an extra layer of abstraction to the process. As a result, virtual servers take a performance hit. I can't tell you exactly how much of a performance hit to expect because it depends on a number of factors, such as the virtualization product being used, the available hardware resources, the load that other virtual servers are placing on the hardware, and how efficiently the guest and host OSs are configured.

Which Virtualization Software Should You Use?
You can use Hyper-V or third-party software to virtualize Exchange 2007. For Exchange 2003, you can use Microsoft Virtual Server 2005 R2 or third-party software. Although Microsoft doesn't officially support using Hyper-V with Exchange 2003, I've found that it works really well.

Although Microsoft typically discourages customers from using third-party virtualization software, they support doing so in some cases. VMware's ESX Server is one such case. For more information about running Exchange on third-party virtualization products, read "Support policy for Microsoft software running in non-Microsoft hardware virtualization software."

I recommend that you host your virtual Exchange 2007 servers on Hyper-V. I also recommend that you use Hyper-V for your Exchange 2003 servers for two main reasons:

Note that an Exchange server must have x64 processors that support hardware-level virtualization to use Hyper-V. Intel and AMD offer processors with this support. In Intel processors, the support is called Intel Virtualization Technology (Intel VT).  In AMD processors, the support is called AMD Virtualization (AMD-V).

Microsoft offers two Hyper-V products: Windows Server 2008 Hyper-V, which is a role in Windows Server 2008, and Microsoft Hyper-V Server 2008, which is a standalone server-virtualization product that you can download from the Microsoft website for free. Hyper-V Server 2008 doesn't include the Server 2008 OS or Server Core. (For more information about the differences between these two products, see "What You Need to Know About Microsoft Hyper-V Server 2008.") You can use either Hyper-V product when virtualizing Exchange.

Items to Consider
Once you've decided to virtualize you Exchange organization using Hyper-V, you need to think through the implementation. Here are some items to consider:

Dedicated network cards. A server's hardware can become a performance bottleneck. One hardware component that is prone to becoming a bottleneck is the network card. Fortunately, Hyper-V lets you configure each virtual machine to use a dedicated network card.

I recommend using a dedicated network card because you're still going to have to perform nightly backups of mailbox servers. A lot of administrators assume they can make a backup by creating an offline snapshot of the virtual hard drive (i.e., the .vhd file). Although true, there are two problems with doing backups this way. First, snapshot backups require you to shut down the virtual machine—and shutdowns aren't practical in most organizations. Second, if you are only making snapshot backups, your transaction log files are never committed because that process occurs as a part of a normal online backup. Given the backup issue and the low cost of network cards, using dedicated network cards for each virtual server is a no brainer, assuming your server has enough free expansion slots.

Note that you can use the Microsoft Volume Shadow Copy Service (VSS) to perform backups. Although VSS decreases the bandwidth consumed by backups, the server will still perform better in general if it has dedicated network cards.

The host OS's configuration. When you're virtualizing Exchange, it's easy to concentrate on the virtual servers and forget about the host OS. Keep in mind that if the host OS is poorly configured, your virtual server's performance will suffer. Granted, when you're using Hyper-V, the guest OS communicates directly with the server hardware in most cases. Even so, the hardware is being shared between the guest OSs and the host OS. A poorly configured host OS consumes hardware resources that could be better used by the guest OSs.

Probably the worst configuration mistake that I have ever seen was when someone stored all of the .vhd files on the same drive as the pagefile, which caused a tremendous performance hit. Other configuration-related issues are discussed in the sections below.

The host OS's memory. You need to make sure that the host OS has enough memory to do its job efficiently. I recommend dedicating a bare minimum of 2GB of memory to the host OS. The machine should have enough physical memory on top of the first 2GB to meet the allocations that you've made to your virtual servers. For example, if a virtualized Exchange server requires 4GB of RAM, the host OS machine will need no less than 6GB of RAM. You also need to factor in the memory requirements of any other virtual servers that are being hosted on the server.

The host OS's applications. The host OS shouldn't be pulling double duty as a web server or file server. Microsoft's guidelines for running Exchange in a virtualized environment stipulate that the host OS should be used only for hosting virtual machines and shouldn't be running any additional server applications other than management software (e.g., antivirus software).

As I just mentioned, Microsoft provides guidelines for virtualizing Exchange. You can read those guidelines in the article "Microsoft Support Policies and Recommendations for Exchange Servers in Hardware Virtualization Environments." I discuss many of the guidelines here, but space limitations prohibit me from covering all of them. So, I recommend that you take the time to read that article.

"Microsoft Support Policies and Recommendations for Exchange Servers in Hardware Virtualization Environments" also outlines Microsoft's support policies for virtualizing Exchange. The requirements involved in the support policies vary considerably depending on whether a server is running Exchange 2007 or Exchange 2003, so I'm going to talk about each set of requirements separately. Before I talk about the version-specific aspects of the virtualization process, though, let's look at the general approaches to virtualization.

The General Approaches to Virtualization
There are three main approaches that you can use to virtualize Exchange. The first approach involves setting up a virtual server, then performing a clean Exchange installation. This new Exchange installation is a member of the existing Exchange organization. With this approach, it's easy to define the server's role within the Exchange organization and migrate any necessary mailboxes or public folders to the virtual machine. In addition, this approach minimizes the amount of time Exchange resources are unavailable. You simply perform a migration, then decommission your old Exchange server once the migration process is complete.

The second approach is to use a physical-to-virtual (P2V) tool such as Microsoft's System Center Virtual Machine Manager (SCVMM) or Vizioncore's vConverter. Such a tool can perform P2V conversions without having to do all of the work involved in the third approach. However, P2V tools typically aren't free.

The third approach involves creating a virtual instance of the physical Exchange server. This approach is more tedious than performing a simple migration. Plus, users will experience a considerable amount of down time and there's more room for error. However, this approach results in a perfect, virtualized image of the physical Exchange server. In addition, it leaves the original Exchange server and all the related records in Active Directory (AD) unchanged. If something were to go horribly wrong during the virtualization process, you can always turn off the virtual server, power up the Exchange server, and be back online within a matter of minutes. For these reasons, I prefer to use the third approach, so I'll cover that approach here. However, in some organizations using this approach might be impractical because of the requirement for taking Exchange offline.

Here are the steps involved in implementing the third approach:

Note that Hyper-V contains an option to create a virtual hard drive based on a physical drive. As tempting as it might be to use this option in place of performing these 15 steps, you can't use it to create a virtual instance of the server's system drive. When you try to boot off of a virtual hard drive that was created in this manner, it will cause the blue screen of death halfway through the boot process.

You can use the option to create a virtual hard drive based on a physical hard drive as a way of virtualizing any hard drive that isn't directly involved in the boot process. The only catch is that creating a virtual drive this way is really slow. It has been my experience that it's usually faster to use the backup and restore approach I just described.

Exchange 2003-Specific Requirements
Here are some version-specific requirements for virtualizing Exchange 2003:

Exchange 2007-Specific Requirements
By far the most important requirement when virtualizing Exchange 2007 is that you must plan the way the server roles are hosted. You shouldn't virtualize the Unified Messaging server role, but virtualizing all the other roles is fair game. Typically, the Hub Transport and Client Access server roles are ideal virtualization candidates because they usually consume a relatively low amount of server resources, except in very large deployments. In addition, they don't have any real storage requirements (e.g., no mailbox databases).

The Edge Transport server role might also be a good virtualization candidate because edge transport servers typically consume a fairly low amount of disk and CPU time. However, I'm a bit apprehensive about virtualizing an edge transport server because it's designed to reside at the network perimeter. Supposedly, an edge transport server can run securely in a virtual environment, but the only way that I would consider virtualizing one would be if the host OS was not a domain member and the other virtual servers residing on the physical server were also intended to reside at the network perimeter.

Mailbox Server roles are the most resource intensive of the Exchange roles that can be virtualized. Although a mailbox server can be virtualized, virtualizing it might not make sense if it's carrying a heavy workload.

Virtualizing Mailbox Servers in Exchange 2007
For the most part, virtual machines can communicate directly with the server hardware, with one notable exception: Calls to the disk subsystem must still pass through the host OS. So, if you're planning on virtualizing mailbox servers, you'll want to pair the mailbox servers other types of virtual servers that aren't as I/O intensive. You'll also have to decide how you want to configure the virtual server's virtual hard drives.

The more advanced configurations are beyond the scope of this article, so I'll discuss only the basics. For a simple mailbox server, Microsoft recommends using three separate sets of spindles: one for the OS, one for the mailbox database, and one for the transaction logs. (Optionally, you can include a spindle for the pagefile and a spindle for the Exchange binaries.) On a physical server, you can install three separate hard drives for the three spindles. If you have more than a dozen mailboxes on an Exchange server, you'll probably want to use disk arrays for the database and transaction logs rather than individual hard drives.

I have seen a few virtual Exchange deployments in which the administrator maintained this separation of data by creating multiple virtual hard drives and configuring Exchange accordingly. The problem with this type of deployment is that having separate virtual hard drives really doesn't do you much good unless the virtual hard drives exist on separate physical hard drives. Although having separate virtual hard drives will help you to recover if one of those virtual hard drives becomes corrupted, you aren't protected against a physical drive failure. If the physical drive fails, you'll lose all the virtual drives that are stored on it.

Another problem with placing all your virtual hard drives on the same physical drive is performance. All the Exchange-related read/write I/O will be directed to a single physical device. This causes a serious performance bottleneck for all but the smallest Exchange organizations.

You could create a RAID array and create all your virtual hard drives on a RAID volume. Assuming that the RAID array is fault tolerant, you would be protected against the failure of an individual hard drive. However, you would still have to deal with the possibility of a controller failure. In addition, an I/O bottleneck might still be an issue, depending on the array's performance. Generally speaking, you would be better off scattering your virtual hard drive files across several small disk arrays than placing everything onto one large array.

The guidelines I just described for virtualizing mailbox servers are good for small-to-midsized businesses (SMBs). However, for larger organizations, they likely wouldn't work because I simplified the mailbox server configuration. So what is a large enterprise to do if they want to virtualize a mailbox server? My recommendation would be to use a SAN and to store all your Exchange volumes on dedicated LUN storage devices.

A Good Start
If you're interested in virtualizing your Exchange organization, you should check out Hyper-V. Hyper-V performs much better than Microsoft's previous virtualization products. I've given you an overview of what you should consider, the processes you can follow, and the requirements you need to meet to virtualize Exchange 2007 and Exchange 2003 with Hyper-V. However, because this is an overview and not meant to be all-inclusive, you'll need to do more research. (The Learning Path at the top of the web page provides some references you can check out.) You should put the same level of research, planning, and testing into your virtual servers that you would give a physical server.