Server virtualization technologies have become so commonplace that they're the de facto standard for server deployment in many organizations. It's becoming more and more common to run into data center environments that operate with the assumption that all new servers will be deployed as virtual guests—unless there's some specific reason not to virtualize. This situation is a significant change from even just a few years ago when the question was reversed, and servers were deployed on physical equipment unless there was a specific reason to virtualize.
So, what about Microsoft Exchange Server? Should you virtualize some or all of an Exchange environment and take advantage of the consolidation, optimization, and flexibility options that virtualization infrastructure provides? The reality is that Exchange environments, particularly those running Exchange Server 2010, can be robustly deployed on virtual servers as long as sufficient resources are allocated to virtual guests and the virtual hosts are scaled correctly. Deploying Exchange improperly in a virtual environment can lead to slowness and other performance problems, and can decrease management confidence in virtualization as a whole, so it's vital to review virtualization design criteria for Exchange in advance.
Microsoft's Virtualization Support Story
The support story for Microsoft products running on virtualization hardware is long and complicated. Until several years ago, Microsoft offered limited support for its flagship server products, such as Microsoft SQL Server, SharePoint, and Exchange, and left open the option that a support problem might need to be duplicated on physical hardware if support technicians couldn't determine the nature of the problem in a virtual environment. Adding to Microsoft's weak support story around the time Exchange Server 2007 was released, Microsoft's own virtualization product at the time, Virtual Server 2005 R2, wasn't a hypervisor-based product and couldn't virtualize 64-bit guests. Therefore, support for virtualization of a 64-bit–only product such as Exchange 2007 was lacking.
Two significant developments changed this story: The first was Microsoft's release of a 64-bit–capable hypervisor, Hyper-V; and the second was the development of a program called the Server Virtualization Validation Program (SVVP), which outlined Microsoft's official support stance on running its products on third-party hypervisor virtualization platforms, such as VMware ESX Server and Citrix XenServer. This program, outlined in the Microsoft article "Support policy for Microsoft software running in non-Microsoft hardware virtualization software" (support.microsoft.com/kb/897615), allowed for support of Microsoft products on third-party virtualization products that were validated by Microsoft and complied with certain criteria, namely the ability for guest sessions to have direct access to hardware resources via a virtualization hypervisor. These two developments opened the floodgates for Microsoft servers running on virtual guests and gave peace of mind to organizations that needed to deploy supported solutions.
Exchange Virtualization Support
Exchange has been a stubborn convert for virtualization over the years. One of the main reasons for this is the fact that Exchange Mailbox servers have traditionally had high performance and disk I/O requirements, which can sometimes be a challenge to replicate on virtual hardware. Although possible to run in a virtual environment, Exchange would consume such a large portion of the resources of the host that the consolidation benefits of virtualization would be minimized. Combine this situation with Microsoft's support stance, and you can see why Exchange server has been one of the applications that has trailed many others in the number of virtualized systems in production.
Exchange Server 2003 was seldom virtualized, except for a few isolated front-end Outlook Web Access (OWA) servers or bridgehead servers. Even in those cases, Microsoft didn't support many of the configurations. Exchange 2007 was the first version to gain broad virtualization support, often at the Client Access and Hub Transport server role tiers but rarely for the Mailbox server role. Exchange 2010, however, is positioned as a great version to virtualize because of both virtualization technology advances and reduction of disk I/O requirements for the Mailbox role that Microsoft has achieved. Disk I/O in Exchange 2010 is significantly less than it is in Exchange 2007, which in itself is less than an equivalent Exchange 2003 server. As a result, many organizations are looking at virtualizing their new Exchange 2010 systems.
There are some limitations to virtualization of Exchange 2010 server roles. For example, Microsoft doesn't support virtualization of the Unified Messaging role. All other roles, however—Client Access, Hub Transport, Edge Transport, and Mailbox—are supported, provided the virtualization software is a member of the aforementioned SVVP.
In addition, Microsoft doesn't support using the Exchange 2010 native mailbox high-availability option, database availability groups (DAGs), on virtual hosts configured for host high availability. This limitation applies to technologies such as VMware's V-Motion, Citrix's XenMotion, Hyper-V Live Migration, and any other solution that automatically fails over the guest sessions from a downed host to another host server. In general, the preferred option would be to use DAG replicas, which have significant advantages, and simply deploy hosts that house the Exchange Mailbox servers without the high-availability options in the host virtualization software.