Applies to: Exchange Server 2010 SP3
Topic Last Modified: 2012-11-13
You can deploy Microsoft Exchange Server 2010 in a virtualized environment. This topic provides an overview of the scenarios that are supported for deploying Exchange 2010 on hardware virtualization software.
The following terms are used in this topic to discuss Exchange virtualization:
- Cold boot Refers to the action of
bringing a system from a power-off state into a clean start of the
operating system. No operating system state has been persisted in
- Saved state When a virtual machine is
powered off, hypervisors typically have the ability to save the
state of the virtual machine, so when the machine is powered back
on, it returns to that saved state rather than going through a cold
- Planned migration When a system
administrator initiates the move of a virtual machine from one
hypervisor host to another, the action is a planned
migration. The action could be a single migration, or a system
administrator could configure automation to move the virtual
machine on a timed basis. A planned migration could also be the
result of some other event that occurs in the system, other than
hardware or software failure. The key point is that the Exchange
virtual machine is operating normally and needs to be relocated for
some reason. This relocation can be done via technology, like Live
Migration or vMotion. However, if the Exchange virtual machine or
the hypervisor host where the virtual machine is located
experiences some sort of failure condition, the outcome isn’t
characterized as a planned migration.
Requirements for Hardware Virtualization
Microsoft supports Exchange 2010 in production on hardware virtualization software only when all the following conditions are true:
- The hardware virtualization software is running one of the
- Windows Server 2008 with Hyper-V technology
- Windows Server 2008 R2 with Hyper-V technology
- Microsoft Hyper-V Server 2008
- Microsoft Hyper-V Server 2008 R2
- Microsoft Hyper-V Server 2012
- Any third-party hypervisor that has been validated under the
Windows Server Virtualization Validation
Note: Deployment of production Exchange servers on Windows Azure virtual machines is not supported.
- Windows Server 2008 with Hyper-V technology
- The Exchange guest virtual machine has the following
- It is running Exchange 2010. This includes Exchange 2010
Hosting Mode, available in Exchange 2010 SP1 and Exchange 2010
- It is deployed on Windows Server 2008 with SP2 (or later
versions) or on Windows Server 2008 R2 RTM (or later
Note: When you install Exchange 2010 in a Hyper-V environment, you may receive the following error message: "Hub Transport Server role installation failed." For virtualized Active Directory servers, we recommend that you disable the time sync integration component, and then set the time to a reliable external time provider before you install the Hub Transport role. This recommendation is especially important if your host is joined to the domain that the virtual machine is hosting.
- It is running Exchange 2010. This includes Exchange 2010 Hosting Mode, available in Exchange 2010 SP1 and Exchange 2010 SP2.
For deployments of Exchange 2010 SP2 or of Exchange 2010 SP1:
- All Exchange 2010 server roles, including Unified Messaging,
are supported in a virtual machine. Unified Messaging virtual
machines have the following special requirements:
- Four virtual processors are required for the virtual machine.
Memory should be sized using standard best practices guidance. For
more information, see Understanding Memory
Configurations and Exchange Performance.
- Four physical processor cores are available for use by each
Unified Messaging role virtual machine at all times. This
requirement means that no processor oversubscription can be in use.
This requirement affects the ability of the Unified Messaging role
virtual machine to use physical processor resources. For more
information, see the Virtualizing Unified Messaging
- Four virtual processors are required for the virtual machine. Memory should be sized using standard best practices guidance. For more information, see Understanding Memory Configurations and Exchange Performance.
- Exchange server virtual machines (including Exchange Mailbox
virtual machines that are part of a database availability group, or
DAG), may be combined with host-based failover clustering and
migration technology, as long as the virtual machines are
configured such that they will not save and restore state on disk
when moved or taken offline. All failover activity must result in a
cold boot when the virtual machine is activated on the target node.
All planned migration must either result in shutdown and cold boot,
or an online migration that makes use of a technology like Hyper-V
Live Migration. Hypervisor migration of virtual machines is
supported by the hypervisor vendor; therefore, you must ensure that
your hypervisor vendor has tested and supports migration of
Exchange virtual machines. Microsoft supports Hyper-V Live
Migration of these virtual machines.
For deployments of the release to manufacture (RTM) version of Exchange 2010:
- Exchange 2010 server roles except for Unified Messaging are
supported in a virtual machine.
- Microsoft doesn't support combining Exchange high availability
solutions (such as DAGs) with hypervisor-based clustering, high
availability, or migration solutions that will move or
automatically failover mailbox servers that are members of a DAG
between clustered root servers. DAGs are supported in hardware
virtualization environments, provided the virtualization
environment doesn't employ clustered root servers, or the clustered
root servers have been configured to never failover or
automatically move mailbox servers that are members of a DAG to
another root server.
- The storage used by the Exchange guest machine for storage of
Exchange data (for example, mailbox databases or Hub transport
queues) can be virtual storage of a fixed size (for example, fixed
virtual hard disks (VHDs) in a Hyper-V environment), SCSI
pass-through storage, or Internet SCSI (iSCSI) storage.
Pass-through storage is storage that's configured at the host level
and dedicated to one guest machine. All storage used by an Exchange
guest machine for storage of Exchange data must be block-level
storage because Exchange 2010 doesn't support the use of network
attached storage (NAS) volumes. Also, NAS storage that's presented
to the guest as block-level storage via the hypervisor isn't
supported. The following virtual disk requirements apply for
volumes used to store Exchange data:
- Virtual disks that dynamically expand aren't supported by
- Virtual disks that use differencing or delta mechanisms (such
as Hyper-V's differencing VHDs or snapshots) aren't supported.
Note: In a Hyper-V environment, each fixed VHD must be less than 2,040 GB. For supported third-party hypervisors, check with the manufacturer to see whether any disk size limitations exist.
- Virtual disks that dynamically expand aren't supported by Exchange.
- Only management software (for example, antivirus software,
backup software, or virtual machine management software) can be
deployed on the physical root machine. No other server-based
applications (for example, Exchange, SQL Server, Active Directory,
or SAP) should be installed on the root machine. The root machine
should be dedicated to running guest virtual machines.
- Some hypervisors include features for taking snapshots of
virtual machines. Virtual machine snapshots capture the state of a
virtual machine while it's running. This feature enables you to
take multiple snapshots of a virtual machine and then revert the
virtual machine to any of the previous states by applying a
snapshot to the virtual machine. However, virtual machine snapshots
aren't application aware, and using them can have unintended and
unexpected consequences for a server application that maintains
state data, such as Exchange. As a result, making virtual machine
snapshots of an Exchange guest virtual machine isn't supported.
- Many hardware virtualization products allow you to specify the
number of virtual processors that should be allocated to each guest
virtual machine. The virtual processors located in the guest
virtual machine share a fixed number of logical processors in the
physical system. Exchange supports a virtual processor-to-logical
processor ratio no greater than 2:1. For example, a dual processor
system using quad core processors contains a total of 8 logical
processors in the host system. On a system with this configuration,
don't allocate more than a total of 16 virtual processors to all
guest virtual machines combined.
- When you calculate the total number of virtual processors
required by the root machine, you must also account for both I/O
and operating system requirements. In most cases, the equivalent
number of virtual processors required in the root operating system
for a system hosting Exchange virtual machines is 2. This value
should be used as a baseline for the root operating system virtual
processor when calculating the overall ratio of physical cores to
virtual processors. If performance monitoring of the root operating
system indicates you're consuming more processor utilization than
the equivalent of 2 processors, you should reduce the count of
virtual processors assigned to guest virtual machines accordingly,
and verify that the overall virtual processor-to-physical core
ratio is no greater than 2:1.
- The operating system for an Exchange guest machine must use a
disk that has a size equal to at least 15 GB plus the size of
the virtual memory that's allocated to the guest machine. This
requirement is necessary to account for the operating system and
paging file disk requirements. For example, if the guest machine is
allocated 16 GB of memory, the minimum disk space needed for
the guest operating system disk is 31 GB.
In addition, it's possible that guest virtual machines may be prevented from directly communicating with fibre channel or SCSI host bus adapters (HBAs) installed in the root machine. In this event, you must configure the adapters in the root machine's operating system and present the LUNs to guest virtual machines as either a virtual disk or a pass-through disk.
- Exchange Jetstress 2010 is supported for use in virtual guest
instances deployed on one of the following hypervisors. Jetstress
is not supported when used in virtual guest instances running under
any other hypervisor.
- Windows Server 2008 R2 (or newer) with Hyper-V technology
- Hyper-V Server 2008 R2 (or newer)
- VMware ESX 4.1 (or newer)
- Windows Server 2008 R2 (or newer) with Hyper-V technology
We support running the Microsoft Exchange Server Jetstress 2010 tool in a guest virtual machine if it’s deployed on one of the following host computers:
- Microsoft Windows Server 2008 R2, or a later version
- Microsoft Hyper-V Server 2008 R2, or a later version
- VMware ESX 4.1, or a later version
Root Machine Storage Requirements
The minimum disk space requirements for each root machine are as follows:
- Root machines in some hardware virtualization applications may
require storage space for an operating system and its components.
For example, when running Windows Server 2008 with Hyper-V, you
will need a minimum of 10 GB to meet the requirements for
Windows Server 2008. For more details, see Windows Server 2008 R2 System Requirements. Additional
storage space is also required to support the operating system's
paging file, management software, and crash recovery (dump)
- Some hypervisors maintain files on the root machine that are
unique to each guest virtual machine. For example, in a Hyper-V
environment, a temporary memory storage file (BIN file) is created
and maintained for each guest machine. The size of each BIN file is
equal to the amount of memory allocated to the guest machine. In
addition, other files may also be created and maintained on the
host machine for each guest machine.
Exchange Storage Requirements
Requirements for storage connected to a virtualized Exchange server are as follows:
- Each Exchange guest machine must be allocated sufficient
storage space on the root machine for the fixed disk that contains
the guest's operating system, any temporary memory storage files in
use, and related virtual machine files that are hosted on the host
machine. In addition, for each Exchange guest machine, you must
also allocate sufficient storage for the message queues on the Hub
Transport and Edge Transport servers and sufficient storage for the
databases and log files on Mailbox servers.
- Storage used by Exchange should be hosted in disk spindles that
are separate from the storage that's hosting the guest virtual
machine's operating system.
- Configuring iSCSI storage to use an iSCSI initiator inside an
Exchange guest virtual machine is supported. However, there will be
reduced performance in this configuration if the network stack
inside a virtual machine isn't full-featured (for example, not all
virtual network stacks support jumbo frames).
Exchange Memory Requirements and Recommendations
Some hypervisors have the ability to oversubscribe or dynamically adjust the amount of memory available to a specific guest machine based on the perceived usage of memory in the guest machine as compared to the needs of other guest machines managed by the same hypervisor. This technology makes sense for workloads in which memory is needed for brief periods of time and then can be surrendered for other uses. However, it doesn't make sense for workloads that are designed to use memory on an ongoing basis. Exchange, like many server applications with optimizations for performance that involve caching of data in memory, is susceptible to poor system performance and an unacceptable client experience if it doesn't have full control over the memory allocated to the physical or virtual machine on which it’s running.
Many of the performance gains in recent versions of Exchange, especially those related to reduction in I/O, are based on highly efficient usage of large amounts of memory. When that memory is no longer available, the expected performance of the system can't be achieved. For this reason, memory oversubscription or dynamic adjustment of virtual machine memory should be disabled for production Exchange servers.
Size the memory for guest machines using the same methods as used for physical deployments. You can find details about memory sizing for Exchange 2010 server roles in Understanding Memory Configurations and Exchange Performance. For additional guidance, see the “Application Considerations” section of a white paper written by the Microsoft Hyper-V team, available for download at Implementing and Configuring Dynamic Memory.
Host-based Failover Clustering and Migration for Exchange
Here are answers to some frequently asked questions about host-based failover clustering and migration technology with Exchange 2010 DAGs.
- Does Microsoft support third-party migration
Microsoft can’t make support statements for the integration of third party hypervisor products using these technologies with Exchange, because these technologies aren’t part of the Server Virtualization Validation Program (SVVP). The SVVP covers the other aspects of our support for third-party hypervisors. You need to ensure that your hypervisor vendor supports the combination of their migration and clustering technology with Exchange. Simply put, if your hypervisor vendor supports their migration technology with Exchange, then we support Exchange with their migration technology.
- How does Microsoft define host-based failover
Host-based failover clustering refers to any technology that provides the automatic ability to react to host-level failures and start affected virtual machines on alternate servers. Use of this technology is supported given that, in a failure scenario, the virtual machine is coming up from a cold boot on the alternate host. This technology helps to make sure that the virtual machine never comes up from a saved state that is persisted on disk because it will be stale relative to the rest of the DAG members.
- What does Microsoft mean by migration support?
Migration technology refers to any technology that allows a planned move of a virtual machine from one host machine to another host machine. This move could also be an automated move that occurs as part of resource load balancing, but it isn’t related to a failure in the system. Migrations are supported as long as the virtual machines never come up from a saved state that is persisted on disk. This means that technology that moves a virtual machine by transporting the state and virtual machine memory over the network with no perceived downtime is supported for use with Exchange. A third-party hypervisor vendor must provide support for the migration technology, while Microsoft will provide support for Exchange when used in this configuration.
Warning: In the case of Microsoft Hyper-V, the live migration option is supported, but the quick migration option is not supported. It’s important to note that when you select the Move operation on a virtual machine in a Hyper-V environment, the default behavior is actually to perform a quick migration. To stay in a supported state with Exchange SP1 and Exchange SP2 DAG members, it’s critical that you use the live migration option, as shown in the following figure.
Virtualizing Unified Messaging Servers
Unlike Exchange 2010 RTM, Exchange 2010 SP1 and SP2 support the Unified Messaging (UM) role on Hyper-V and other supported hypervisors. Exchange 2010 SP1 or Exchange 2010 SP2 must be deployed for UM support because the UM role is dependent on a media component provided by Microsoft Lync. Prior to the release of Exchange 2010 SP1, the Lync engineering team had enabled high-quality, real-time audio processing in a virtual deployment. Beginning with Exchange 2010 SP1, the changes were integrated into the UM role.