Problem solve Get help with specific problems with your technologies, process and projects.

Best practices for virtualizing Exchange 2010 on vSphere

Observing best practices and watching for common oversights will go a long way when virtualizing Exchange 2010 on VMware vSphere.

Although virtualizing Exchange Server 2010 might seem like the endgame, the process is rarely straightforward and...

optimal deployment strategies aren't always obvious. Administrators must take additional steps to optimize performance, correct resource shortages or troubleshoot problems that arise as a consequence of Exchange 2010 virtualization.

Maximizing virtualized Exchange 2010 performance

More from this series

Evaluating VMware vSphere for Exchange 2010 virtualization

VMware vSphere necessities for Exchange 2010 virtualization

Step-by-step: Exchange 2010 virtualization on vSphere

Many instances of virtualized Exchange 2010 often run poorly because administrators didn't do enough planning. The primary reason for unsatisfactory deployments -- or outright failures -- is disregarding best practices. Here's what administrators need to know:

  • When allocating processors, only assign multiple virtual CPUs (vCPUs) if you can determine that your Exchange virtual machines (VMs) can really take advantage of the additional processors; otherwise, you're wasting resources. Start with the smallest number of vCPUs and work your way up as more processors are needed.
  • Ensure that the total number of vCPUs assigned to all Exchange 2010 VMs is equal to (or less than) the total number of cores on the ESX host machine. If you assign more vCPUs to mission-critical VMs than the physical host has available, you are overcommitting CPUs, and taking a chance that your Exchange VMs won't have CPU cycles when they're needed. Instead of a 1:1 mapping of cores to vCPUs, use CPU reservations to protect those CPU resources for Exchange VMs.
  • Overcommitting memory with VMware vSphere is common -- and even recommended -- but don't overcommit memory when virtualizing Exchange 2010. If you do, you'll have to deal with memory ballooning, compression and paging -- all of which will diminish performance.
  • Use storage multi-pathing to ensure storage area network (SAN) availability. VMware recommends providing a minimum of four paths from a VMware ESX host to a storage array, which means the host requires at least two host bus adapter (HBA) ports, two Fibre Channel ports and two SAN ports.
  • Allocate separate network adapters and networks for VMotion, VMware fault tolerant (FT) logging traffic and ESX console access management. Use at least two network adapters for Exchange production traffic to leverage VMware network interface card (NIC) teaming capabilities. Generally, at least four network adapters are recommended per ESX host.
  • Use the VMXNET3 virtual network adapter driver instead of the default E1000. In mission-critical VMs like Exchange 2010, the para-virtualized VMXNET3 will result in better performance. Also, ensure that VMware Tools is installed on each VM as the VMXNET3 virtual NIC driver.
  • Don't skimp on host server hardware. No amount of virtualization features can fix old or slow hardware.
  • When virtualizing Exchange 2010, make sure you're up-to-date with the latest service pack.
  • Use vSphere High Availability (HA) to automatically restart your Exchange VMs in the event of a host failure.

Improve virtualized Exchange 2010 resource utilization

Virtualization is all about maximizing each physical server's resources. But you never want to over-maximize your resources by skimping on CPU, memory and I/O allocation. That's a recipe for poor application performance and end-user complaints.

First, use resource pools and reservations. Reservations involve individual VMs, and resource pools create reservations for multiple VMs in the pool. These tactics allow you to protect your Exchange 2010 VM's CPU and memory resources from other less-critical VMs with variable resource needs in the same infrastructure cluster.

For example, by creating a pool called "Exchange2010," and putting all Exchange VMs inside and setting CPU and memory reservations on that pool, you are ensuring solid Exchange performance (at least for CPU and memory).

Next, use the VMware Distributed Resource Scheduler (DRS), which monitors VMs in a cluster, to ensure they're receiving the CPU and memory they are configured for on a particular ESXi host. If the VMs aren't getting the resources needed, DRS automatically moves the VMs to another ESXi host.

And last, employ the Storage Distributed Resource Scheduler (SDRS). VSphere 5's SDRS does for storage what DRS does for CPU and memory. If Exchange VM virtual disks are experiencing high latency in their current data store, or if the data store is about to run out of space, SDRS will use sVMotion to move those VM virtual disks to another, better-performing or spacious data store without downtime to end users and applications.

Common problems with virtualized Exchange 2010 performance

Even a well-planned and well-executed Exchange 2010 virtualization project is likely to run into problems. These troubles typically involve resources and storage:

You determine that an Exchange VM is performing poorly. Investigate each VM's performance and compare it to the performance monitored with the previous physical deployment. You'll probably find that the afflicted VMs are short of computing resources, so allocate additional resources to boost performance or use vMotion to move the Exchange VM to another host.

You determine that storage capacity for mailboxes is running short. It's possible to deploy an archiving or purging system to control data growth, but this is a separate project. Instead, use virtualization tools to dynamically expand VM disks or add more virtual disks to a VM.

You might also need to add more physical disks or deploy other data-reduction tactics, such as data deduplication. It's also important to use capacity planning techniques to ensure adequate storage over time.

You determine that storage performance is inadequate. Storage-performance monitoring will reveal unexpected latency between the Exchange VMs and the SAN. Use SDRS to move the virtual disk to another data store. As a more permanent fix, you could address the underlying latency issue in the architecture.

In the end, the key to success when virtualizing Exchange 2010 is proper planning and education and the implementation of best practices. Exchange 2010 virtualization is proven, and advanced virtualization features will make Exchange more reliable and improve uptime, while making the administrator's life easier.

About the author
David Davis is the author of the best-selling VMware vSphere video training library from TrainSignal. He has written hundreds of virtualization articles on the Web, is a vExpert, VCP, VCAP-DCA, and CCIE #9369 with more than 18 years of enterprise IT experience. His website is

Dig Deeper on Exchange Server setup and troubleshooting