Hardware requirements only scratch the surface. Virtualizing Exchange Server 2010 also requires attention to storage requirements, memory considerations and fault tolerance.
Hardware requirements for virtualizing Exchange
The hardware requirements for Exchange Server 2010 vary greatly depending on the server roles installed on the anticipated workload. As such, the minimum hardware requirements on Microsoft’s website are often completely inadequate.
Determining the hardware requirements for most Exchange Server roles is fairly straightforward. There are numerous TechNet articles that can guide you through the planning process. Hardware planning for the mailbox server role is the most difficult, especially in large deployments. The best way to accurately estimate the role’s hardware requirements is to use the Exchange 2010 Mailbox Server Role Requirements Calculator.
As you plan hardware allocation for virtualized Exchange servers, it is important to remember that Microsoft does not differentiate between physical and virtual deployments of Exchange Server 2010. The hardware requirements are the same regardless of whether you run Exchange on physical hardware or in virtual machines (VMs).
Storage requirements for virtualizing Exchange
Storage requirements are also a consideration when virtualizing Exchange Server 2010. You can configure Exchange Server 2010 to use virtual hard disks that reside locally on the server, or you can connect to a remote storage mechanism through iSCSI. Exchange Server 2010 also supports SCSI pass-through disks.
If you use virtual hard drives for Exchange Server storage, they must be a fixed size. Microsoft does not support dynamically expanding virtual hard drives with Exchange Server. (This isn’t really an issue with VMware, because VMware uses fixed-length virtual hard disks by default.)
If you plan to use iSCSI connectivity, make sure the virtual Exchange server uses a full-featured network stack. If the server does not support the use of jumbo frames, for example, then storage performance may be greatly diminished.
Memory considerations when virtualizing Exchange
Exchange has always been an I/O intensive application, but one of Microsoft’s major design goals in Exchange Server 2010 was to drive down the I/O requirements. With fewer I/O requirements, it is more practical to virtualize Exchange mailbox servers. But in order to achieve decreased I/O levels, Exchange 2010 is designed to use large amounts of memory. That means efficient memory use is critical to the server’s performance.
You should avoid using memory overcommit or Dynamic Memory when virtualizing Exchange Server 2010. Memory overcommit works well for servers that occasionally need extra memory to perform an operation and release that memory when the task is complete. Exchange, however, is a memory-hungry application, and the Mailbox Server role usually consumes all the memory that it can.
No snapshots allowed
One of the most important things to know about virtualizing Exchange Server 2010 is that it doesn’t support VM snapshots. Snapshots make a point-in-time copy of the VM to be used for backup and recovery.
In Exchange Server 2010, the Mailbox Server, Hub Transport Server, and Edge Transport Server roles all use highly transactional internal databases. Using snapshots to revert a virtualized Exchange server to a previous state could therefore have disastrous consequences, especially in organizations that use multiple Exchange servers.
Before the release of Service Pack 1 (SP1), Microsoft didn’t support combining Exchange Server database availability groups with hypervisor-level clusters. Exchange Server 2010 SP1 supports this configuration, but with some limitations. VMs must be configured so that their state is never saved or restored when the VM is taken offline or when a failover occurs.
With all the hardware requirements and resource-allocation considerations, virtualizing Exchange Server 2010 can be a juggling act. VMware (PDF) and Microsoft have released best practices for virtualizing Exchange Server 2010 on their hardware platforms.