vSphere Replication Review (VR) in SRM 5

Ok, so VMware has this new replication method through SRM 5 (Site Recovery Manager) and I think that it is profound due to two reasons.

#1 It allows SMB customers the ability to replicate to a DR site without the need for an enterprise storage array on the back end. Think of the impact here – small companies can now implement a disaster recovery process!

#2 It operates at the vSphere level and allows an administrator the proverbial “single pane of glass” to see the virtual inventory at both locations!

Requirements for Enabling:

  • Virtual Machine version 7
  • Port 44046 and 31031 for sync transfers
  • One vSphere Replication Management Server per/vCenter
  • Must have vSphere 5 and SRM 5 installed

A few noteworthy benefits:

  • Full support of Microsoft VSS
  • Replication agent runs on the ESXi node as a host agent
  • Abstracts the storage layer allowing for replication regardless of the storage on either site
  • VM’s are configured for replication as a property of the virtual machine (you can tag one or all the VMDK’s for replication)
  • Traditional seed loading of the replicated site (such as an external drive)
  • Comes in a handy virtual appliance for quick installation (500 protected vm’s max)
  • Efficient use of bandwidth during replication (through the use of the VR Agent hostd)
  • Does an analysis on previous transfers to predict future ones

A few restrictions due to the way VR operates at the virtual disk layer:

  • You can’t replicate powered off machines (although, you can tag a powered off vm for replication, it won’t replicate until its powered on)
  • You can’t use Storage DRS (sDRS) or Storage vMotion with vSphere Replication.
  • No support for fault tolerance (FT) or Linked Clones
  • Performance hit during the initial sync (can schedule)

VR Replication Recap:

As I look at the technology, I see a lot of similarities to FT (Fault Tolerance). On the primary site, the vm’s disks that are marked for replication are monitored and all I/O blocks that are destined for a VMDK are compared at the replicated site and sent over the WAN to mirror that. This is all based on the Recovery Point objective that the administrator sets up. There are basically two areas where you can set up VR; one place is within SRM or it can be configured on a per vm basis as mentioned above.

All this without the use of snapshots!



  1. Mike says:

    Why no sdrs or svmotion with replication? I understand that you can’t use it with the traditional array based replication of SRM but since vSphere replication is on a vm level I don’t understand why it matters if the vm moves around.

  2. Rick says:


    According to VMware, (per SRM Release notes) – “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.” – http://www.vmware.com/support/srm/srm_releasenotes_5_0_0.html

    SDRS alters the location of the virtual machine without notifying SRM which in turn prevents the vm from being protected in the future. I think that until this communication piece is put in place, this will continue to be unsupported.


  3. Rob says:

    Interesting. It may not be supported but it certainly *appears* to work. I tested by enabling vSphere Replication on a VM, verified that the files did replicate, then performed a Storage vMotion of the protected VM (from one datastore at the protected site to another datastore at the protected site).

    After the storage vMotion completed, VRS automatically performed another full sync of the protected VM. There were no warnings from vCenter at any time during the process. The next step would be a real failover test, I’ll get to that sometime next week and post my results.

Leave a Reply