With the release of Exchange Server 2007 SP1 and Windows Server 2008, Microsoft began supporting Exchange Server 2007 in virtual environments.
However, not every scenario is supported, and Microsoft only recommends and supports a virtual environment if specific conditions are met.
First of all, as I implied, only Exchange 2007 SP1 can run virtually. SP1introduced further improvements to Exchange's I/O footprint, which, I imagine, led to Microsoft's easing of restrictions on the installation in virtual environments.
Second, your Exchange servers must be running under Windows Server 2008; Windows Server 2003-based Exchange servers are out of the question.
Next, your virtual environment needs to be running on Hyper-V or a third-party virtualization provider validated by Microsoft. Validated third-party products include VMware ESX 3.5 updates 2 and 3 and Citrix Xen Server, among others. Microsoft prefers that you use Hyper-V as your virtualization platform, but it's nice to see that it isn't excluding other major players.
One major item of note: If you intend to use unified messaging, that role is not supported in a virtual environment. In fact, it's not recommended that you use virtualization for any services for which real-time communication is required.
I have tested the unified messaging role in a virtual lab and can safely say that this role really needs to run on its own physical server.
There are a number of other items to take into consideration when it comes to running Exchange in a virtual environment. The list below is just a few of the major items. Microsoft provides a complete list of requirements and limitations on TechNet.
- Don't forget to account for the processing and disk needs of the virtual host, particularly if you're using Hyper-V. Under Hyper-V, the root machine needs processors assigned to it, and the root machine will consume processing resources and RAM. As you build your virtual hosts and add virtual machines, makes sure that the virtual processor-to-physical core ratio is no greater than 2:1. That is, if you have a four core machine, do not assign more than eight cores worth of processor to the running virtual machines.
- Understand that Exchange's high-availability features, such as continuous cluster replication, don't mix well with hypervisor-based clustering, such as Hyper-V's quick migration or VMware's VMotion. Microsoft doesn't support combining these technologies. If you choose to forgo VMotion or quick migration on your root server or virtual host, then Exchange's clustering capabilities are fully supported in a virtual environment, although you do lose a significant server availability feature. Of course, you can always run clustered mailbox servers on different virtual hosts as a way to mitigate some of this downside. This limitation would only affect the virtual machines hosting the mailbox server role. The servers housing the other roles should not be limited.
- Microsoft does not support making snapshots of full Exchange virtual servers at the virtual host level due to the fact that most hypervisor-based snapshot tools are not application aware. Snapshots could end up creating a mess if used improperly.
- Even when running in a virtual environment, you need to adhere to design recommendations when it comes to building your virtual servers. If, for example, a physical machine would require 16 GB of RAM for a particular Exchange installation, the virtual machine will too.
- Under Hyper-V, VHDs are limited to 2 TB in size. Size your mailbox stores accordingly.