I have a client who is looking to build a separate vSphere 5 cluster enviroment for a few critical VM’s with failover capabilities to a secondary datacenter.  The primary driver for SRM5 is the new host based replication feature which provides the customer with abilities to replicate the VM’s across ESX hosts that use local storage.  Also, since SRM already incorporates  a feature where you can perform a test failover without innterrupting the production systems/network is a huge win for them.  They will be performing a DR test on these VM’s in a weeks and they refuse to take there chances withDoubleTake.

At VMWorld it was stated that a few limitations exist when using vSphere replication so I just wanted to make sure that it wouldn’t interfere with our goals.  I found the “official” answer in the SRM5 release notes below.

SRM5 Caveats and Limitations

• Interoperability with Storage vMotion and Storage DRS Due to some specific and limited cases where recoverability can be compromised during storage movement, Site Recovery Manager 5.0 is not supported for use with Storage vMotion (SVmotion) and is not supported for use with the Storage Distributed Resource Scheduler (SDRS) including the use of datastore clusters.
• Interoperability with vCloud Director Site Recovery Manager 5.0 is not supported for protection of vCloud Director environments or virtual machines resident within a vCloud Director environment.
• Re-protect and automated failback not supported with vSphere Replication Re-Protect and Automated Failback is only supported with array-replicated virtual machines. Virtual machines configured with vSphere Replication cannot be failed back automatically to the original site using existing recovery plans.
• SRM conversion from per-CPU to per-VM license count is incorrect Some customers who purchased SRM 1.x and SRM 4.0 may still be using per-CPU allocated licenses. There is a known issue in the conversion process from these older per-CPU licenses to per-VM SRM 5.0 licenses wherein the formula for counting how many CPU licenses are used is too lenient. It is possible in this scenario that the conversion will incorrectly grant too many per-VM licenses for SRM 5.0. This is incorrect behavior and will be fixed with a patch for SRM. Please note your license conversion count carefully to ensure you are compliant with the terms and conditions of your license agreement and have not exceeded the number of protected VMs for which you are licensed.