Microsoft now supports Live Migrations for Exchange 2010 SP1 as well as clustered VM hosts, while the below speaks specifically to Hyper-V everything on the approved list of hypervisors will be supported as well, quoting from the announcement:

The updated support guidance applies to any hardware virtualization vendor participating in the Windows Server Virtualization Validation Program (SVVP).

The announcement is here:

http://blogs.technet.com/b/exchange/archive/2011/05/16/announcing-enhanced-hardware-virtualization-support-for-exchange-2010.aspx

and the whitepaper I’m quoting out of is here:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=8647c69d-6c2c-40ca-977e-18c2379b07ad

What I’m quoting below speaks specifically to Hyper-V features, however as mentioned above any vendor that has equivalent features and features on the SVVP is covered as well. The pertinent bits from a support point of view are as follow:

Live Migration

Hyper-V live migration moves running virtual machines from one physical host to another physical host with no impact on availability to users. To achieve this with no impact, Hyper‑V pre-copies the memory of the migrating virtual machine to the destination physical host. As this is occurs, any virtual machine modifications to the virtual machine’s memory pages are tracked and any modified pages are transferred to the destination physical computer. Hyper-V then moves the storage handle for the virtual machine’s VHD files to the destination physical computer and the destination virtual machine is brought online on the destination Hyper-V server.

The guest operating system of the migrating virtual machine is unaware the migration is happening, so no special configuration for the guest operating system is needed.

Live migration requires the failover clustering role to be added and configured on the servers running Hyper-V. In addition, failover clustering requires shared storage for the cluster nodes. This can include an iSCSI or Fibre Channel SAN. All virtual machines are stored in the shared storage area, and the running virtual machine state is managed by one of the nodes.

On a given server running Hyper-V, only one live migration (to or from the server) can be in progress at a given time, which means live migration cannot be used to move multiple virtual machines simultaneously.

We recommend the use of the Cluster Shared Volumes feature of failover clustering in Windows Server 2008 R2 with live migration. Cluster Shared Volumes provides increased reliability when used with live migration and virtual machines, and also provides a single, consistent file namespace so that all servers running Windows Server 2008 R2 see the same storage.

Exchange server virtual machines, including Exchange Mailbox virtual machines that are part of a Database Availability Group (DAG), can 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.

Dynamic Memory

Although dynamic memory might be appropriate for certain applications, dynamic adjustment of virtual machine memory should be disabled for production Exchange servers.

Dynamic memory allows memory on a host virtual server to be pooled and dynamically distributed to virtual machines as necessary. Memory is dynamically added or removed based on current workloads, and is done so without service interruption. 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 that have 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 is 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 cannot be achieved.

Microsoft RemoteFX

Although Microsoft Remote FX may be appropriate for certain applications, it must be disabled for production Exchange servers.

Microsoft RemoteFX in Windows Server 2008 R2 SP1, introduces a new set of remote user experience capabilities that enable a media-rich user environment for virtual desktops, session-based desktops and remote applications. RemoteFX can be deployed to a range of thick and thin client devices, enabling cost-effective, local-like access to graphics-intensive applications and a broad array of end user peripherals, improving productivity of remote users.

Hyper‑V Failover Clustering

The Failover Clustering feature enables you to create and manage failover clusters. A failover cluster is a group of independent computers that work together to increase the availability of applications and services. The clustered servers (called nodes) are connected by physical cables and by software. If one of the cluster nodes fails, another node begins to provide service (a process known as failover). Users experience a minimum of disruptions in service.

A new feature of failover clusters called Cluster Shared Volumes is specifically designed to enhance the availability and manageability of virtual machines. Cluster Shared Volumes are volumes in a failover cluster that multiple nodes can read from and write to at the same time. This feature enables multiple nodes to concurrently access a single shared volume. The Cluster Shared Volumes feature is only supported for use with Hyper-V and other technologies specified by Microsoft.

On a failover cluster that uses Cluster Shared Volumes, multiple clustered virtual machines that are distributed across multiple cluster nodes can all access their virtual hard disk (VHD) files at the same time, even if the VHD files are on a single disk (LUN) in the storage. This means that the clustered virtual machines can fail over independently of one another, even if they use only a single LUN. When Cluster Shared Volumes is not enabled, a single disk (LUN) can only be accessed by a single node at a time. This means that clustered virtual machines can only fail over independently if each virtual machine has its own LUN, which makes the management of LUNs and clustered virtual machines more difficult.

For a two-node failover cluster, the storage should contain at least two separate volumes (LUNs), configured at the hardware level. Do not expose the clustered volumes to servers that are not in the cluster. One volume will function as the witness disk. One volume will contain the files that are being shared between the cluster nodes. This volume serves as the shared storage on which you will create the virtual machine and the virtual hard disk.