
vSphere Replication is a disaster recovery solution that allows you to replicate virtual machines on the same vCenter Server instance or to other instances within the same site, across sites and even to vCloud Air.
The software is distributed as a SUSE Linux appliance (OVF) and fully integrates with vCenter Server once deployed via vSphere Web Client. It works with both versions of vCenter Server – Windows and appliance – and comes readily licensed with vSphere Essentials Plus kit, vSphere Standard, Enterprise and Enterprise Plus and the vCloud Suite editions.
From an architectural standpoint, a vSphere Replication appliance runs fully integrated with vCenter Server where it registers itself as an extension. A main component, vSphere Replication Server handles all replication processes. Multiple servers can be deployed for load balancing purposes in large environments. When replicating between two sites managed by a different vCenter instance, the vSphere Replication appliance must be installed on both vCenter instances. You can also choose to replicate a VM to the same vCenter Server.
Once a replication connection is established, practically any VM can be configured for replication. It is possible to seed the first replica to reduce bandwidth utilization and replication times. Once the source VM and replica are in sync, it is only changed blocks in the VM’s VMDKs that are replicated. For every VM configured for replication, you can independently set a recovery point objective (RPO) ranging from 5 minutes to 24 hours which determines the maximum allowable data loss. You can also set a retention policy for multiple point in time (MPIT) replica instances. This gives you a maximum of 24 snapshots for every replicated VM.
The following diagram (source: VMware), depicts two possible replication scenarios. The one on the left, depicts a replication setup between two vCenter Server instances hosted at different sites. The one on the right, depicts a scenario in which replication is confined to a single vCenter instance with one vCenter Replication appliance managing two vCenter Replication Servers for load balancing.
![]() |
Note: Unlike fault tolerance protected VMs, a replicated VM does not spawn automatically on the target site in case of failure. Instead, it is up to you to recover it from the replica.
This guide will walk you through the steps to set up replication between two vCenter Server instances. The environment consists of two vCSA 6.5 instances each managing nested ESXi 6.5 hosts. Network-wise, both vCenter Servers are running on the same network. However, for replication to work across different networks, WAN links, etc.
Setting up vSphere Replication
1. To begin with the following steps, first you need to download the vSphere Replication 6.5 ISO file from my.vmware.com.
![]() |
3. Right-click on the vCenter Server name and select Deploy OVF Template. Unlike standard OVF deployments, here you’ll need to select 5 files. These include the two VMDKs (3) and the correct OVF, MF and CERT files (4) as shown next.
![]() |
4. Select the datacenter where the appliance will be deployed to.

5. Select the ESXi host where the appliance’s VM will be created.

6. Review the OVF template details just to make sure you’re deploying the correct component and version.

7. Accept the EULA.

8. Choose the configuration type. Here, you have two options to choose from. Quoting VMware: “Selecting higher number of vCPUs ensures better performance of the vSphere Replication Management Server, but might slow down the replications that run on ESXi host systems that have 4 or less cores per NUMA node. If you are unsure what the hosts in your environment are, select 2 vCPUs.“

9. Select a datastore and the appliance’s VM disk provisioning mode.

10. Select the portgroup (network) the appliance will connect to. Also, set the desired IP version (4 or 6) and the method used to assign TCP/IP settings. I selected Static – Manual settings for this example which is what you’ll probably select anyway.

11. Configure the appliance network. All settings are obligatory save for the DNS Search Path.

12. This is just a screen telling you that the appliance will bind to vCenter as an extension.

13. Final chance to review the appliance’s configuration before committing. Press Finish to deploy.

14. As always, you can follow the deployment progress from vSphere Web client.

15. Once the deployment completes, go ahead and power up the appliance.
16. Using a browser, navigate to http://<appliance ip address>:5480. From VAMI, do the following:
17. Select the Configuration tab (2) under VR (1)
18. Type in the password for the SSO administrator account (3).
19. Click on the Save and Restart Service button (4)
20. Accept the SSL certificate when prompted to (5)

Note: You might run into some issues if the vCSA is not correctly registered with the lookup service.
You’ll know that the appliance registered successfully when the VRM (vSphere Replication Management) service status is shown as running.

21. Log out of vCenter Server and log in back again. This will load the new vSphere Replication extension, the icon for which should show up on the Home screen.

22. Repeat step 3-7 on the target vCenter Server.
23. Assuming that the appliance was successfully installed at both ends, it’s now time to configure a replication connection between the two vSphere Replication appliances. To do so, log in the source vCenter Server and click on the vSphere Replication icon under Home. Right-click on the vCenter Server name listed and select Connect to Target Site from the All vSphere Replication Actions menu.
23. Assuming that the appliance was successfully installed at both ends, it’s now time to configure a replication connection between the two vSphere Replication appliances. To do so, log in the source vCenter Server and click on the vSphere Replication icon under Home. Right-click on the vCenter Server name listed and select Connect to Target Site from the All vSphere Replication Actions menu.

24. Type in the IP address of the Platform Services Controller of the remote SSO domain (the one the target vCenter Server participates in) and the corresponding admin credentials. Press Yes to accept the SSL certificate and you should be ready to go.

25. To ensure that the connection between the two vSphere Replication appliances is established, click on the vCenter Server name in Navigator (1). Click the Configure tab and navigate to vSphere Replication (3) -> Replication Servers (4). You should see a Connected icon under the Status column. The same applies to verifying the connection, this time from a vCenter Server viewpoint. Just select vSphere Replication -> Target Sites.

In case of a dropped connection, try re-establishing it by pressing on the Reconnect … icon as shown next. You’ll need to supply the credentials for the PSC at the remote site.

That’s all there is to setting vSphere Replication between vCenter sites which will undoubtedly bolster your disaster recovery contingency plans.
27. Select Replicate to a vCenter Server. The second option is selected when replicating to a vCenter instance hosted on a cloud provider such as vCloud Air.
28. Select the target where the VM will be replicated to. In this example, I’ve selected a vCenter Server at the remote site. The Add Remote Site button is used when you need to add new connections between source and target sites.
29. Any configured vSphere Replication servers available at the remote site are automatically picked for you. Select one from the list or simply accept the default selection.
30. Click on Edit (2) to select a datastore from the target site where the replica will be created. A list of all the datastores managed by the target vCenter instance is displayed. Optionally, expand the details (1) to list additional VM disks. This allows you to set the storage policy, disk format and replication behavior for every individual VM disk.
31. If supported, you can optionally enable guest OS quiescing which allows the replica VM to be restored in a consistent state. This should be enabled only where applications running on a VM specifically call for VSS quiescing. Network compression can also be enabled to reduce bandwidth utilization. This, however, may result in an increased CPU utilization at both ends of the connection.
32. Use the RPO slider (1) to set an acceptable time period for which data can be lost in case of a site failure. Optionally, enabling the Point in time instances option (2) creates multiple instances or recovery points of the VM. A maximum of 24 instances per VM is supported which are converted to snapshots when a replica is restored as a VM.
Note: “The number of replication instances that vSphere Replication keeps depends on the configured retention policy, but also requires that the RPO period is short enough for these instances to be created. Because vSphere Replication does not check whether the RPO settings will create enough instances to keep, and does not display a warning message if the instances are not enough, you must ensure that you set vSphere Replication to create the instances that you want to keep. For example, if you set vSphere Replication to keep 6 replication instances per day, the RPO period should not exceed 4 hours, so that vSphere Replication can create 6 instances in 24 hours.”
33. Review the settings and press Finish to commit.
Note that the VM must be powered on for replication to take place. You can monitor the replication status for a VM from the VM Replication window (3) on the Summary page (2) for the highlighted VM.
Likewise, you can monitor incoming replications on the target vCenter instance as shown in the following screenshot. The same applies to monitoring outgoing replication connections. If Point in Time has been enabled for a VM, a list of all the instances taken to date are displayed under the Point in Time tab. In this example, only one instance has been created thus far.
35. Select the recovery option you wish to use. The first, Synchronize recent changes, cannot be used when the source virtual machine is still powered on to avoid conflicts. Additionally, when selecting this option, the VM must be reachable in order to replicate the latest changes to the target which ensures no loss of data.
In this case, I opted for the second option as shown. Also, notice that the VM I’m about to recover has an associated instance that will show up as a snapshot when the VM is added to the inventory. This allows you to revert to a point in time when the VM was fully functional in terms of the guest OS installed and running applications.
36. Select a location where the VM will be restored.
37. Select the cluster, host or resource pool to which the VM will be restored.
38. The Power on … option is enabled by default but can be disabled if you don’t want the VM powered up on restore. As a precaution, any network card on the VM is left disconnected meaning that they are enabled manually after the VM has been restored. Pressing Finish initiates the recovery process.
Once the VM is restored, you can revert to a snapshot if point in time was enabled. If the source VM is running, you won’t be able to edit its settings unless the source VM is powered off first. This is something you need to keep in mind knowing that the vnics are disabled automatically. Once the VM is restored, you will not be able to restore it a second time.
After the VM is restored, you can safely delete the incoming replication connection for the specified VM from the vSphere Replication tab. This is done by selecting the VM and clicking on the Stop Replication button as shown next. Doing this, deletes the files associated with the replica from the target datastore and removes any corresponding replication settings for the VM at source.
VMware vSphere Replication is a vCenter integrated solution that effectively protects your virtual machines thus complementing any DR strategy you might have in place. Since replication occurs at the host level, vSphere Replication is compatible with a number of storage architectures and technology including SAN, NAS, DAS and vSAN which makes the solution extremely versatile.
From a network perspective, replication traffic is kept in check by using compression and replicating only data that has changed. We’ve also seen that RPO can be set to anywhere from 5 minutes to 24 hours on an individual VM basis. Multiple recovery points (snapshots) and VSS quiescing ensure maximum protection for your VMs and hosted applications.
Replicating a VM
26. Right-click on the VM you wish to replicate, selecting Configure Replication from the All vSphere Replication Actions menu.
27. Select Replicate to a vCenter Server. The second option is selected when replicating to a vCenter instance hosted on a cloud provider such as vCloud Air.

28. Select the target where the VM will be replicated to. In this example, I’ve selected a vCenter Server at the remote site. The Add Remote Site button is used when you need to add new connections between source and target sites.

29. Any configured vSphere Replication servers available at the remote site are automatically picked for you. Select one from the list or simply accept the default selection.

30. Click on Edit (2) to select a datastore from the target site where the replica will be created. A list of all the datastores managed by the target vCenter instance is displayed. Optionally, expand the details (1) to list additional VM disks. This allows you to set the storage policy, disk format and replication behavior for every individual VM disk.

31. If supported, you can optionally enable guest OS quiescing which allows the replica VM to be restored in a consistent state. This should be enabled only where applications running on a VM specifically call for VSS quiescing. Network compression can also be enabled to reduce bandwidth utilization. This, however, may result in an increased CPU utilization at both ends of the connection.

32. Use the RPO slider (1) to set an acceptable time period for which data can be lost in case of a site failure. Optionally, enabling the Point in time instances option (2) creates multiple instances or recovery points of the VM. A maximum of 24 instances per VM is supported which are converted to snapshots when a replica is restored as a VM.
Note: “The number of replication instances that vSphere Replication keeps depends on the configured retention policy, but also requires that the RPO period is short enough for these instances to be created. Because vSphere Replication does not check whether the RPO settings will create enough instances to keep, and does not display a warning message if the instances are not enough, you must ensure that you set vSphere Replication to create the instances that you want to keep. For example, if you set vSphere Replication to keep 6 replication instances per day, the RPO period should not exceed 4 hours, so that vSphere Replication can create 6 instances in 24 hours.”

33. Review the settings and press Finish to commit.

Note that the VM must be powered on for replication to take place. You can monitor the replication status for a VM from the VM Replication window (3) on the Summary page (2) for the highlighted VM.

Likewise, you can monitor incoming replications on the target vCenter instance as shown in the following screenshot. The same applies to monitoring outgoing replication connections. If Point in Time has been enabled for a VM, a list of all the instances taken to date are displayed under the Point in Time tab. In this example, only one instance has been created thus far.

Restoring a VM
34. Log in the target vCenter Server using the vSphere Web client. Select the vCenter Server (1) from Navigator and click on the Monitor (2) tab. Next, click on vSphere Replication (3) and select Incoming Replications (4). Select the VM you want to restore from the Virtual Machine list (5) and click on the Start Recovery button (6).
35. Select the recovery option you wish to use. The first, Synchronize recent changes, cannot be used when the source virtual machine is still powered on to avoid conflicts. Additionally, when selecting this option, the VM must be reachable in order to replicate the latest changes to the target which ensures no loss of data.
In this case, I opted for the second option as shown. Also, notice that the VM I’m about to recover has an associated instance that will show up as a snapshot when the VM is added to the inventory. This allows you to revert to a point in time when the VM was fully functional in terms of the guest OS installed and running applications.

36. Select a location where the VM will be restored.

37. Select the cluster, host or resource pool to which the VM will be restored.

38. The Power on … option is enabled by default but can be disabled if you don’t want the VM powered up on restore. As a precaution, any network card on the VM is left disconnected meaning that they are enabled manually after the VM has been restored. Pressing Finish initiates the recovery process.

Once the VM is restored, you can revert to a snapshot if point in time was enabled. If the source VM is running, you won’t be able to edit its settings unless the source VM is powered off first. This is something you need to keep in mind knowing that the vnics are disabled automatically. Once the VM is restored, you will not be able to restore it a second time.

After the VM is restored, you can safely delete the incoming replication connection for the specified VM from the vSphere Replication tab. This is done by selecting the VM and clicking on the Stop Replication button as shown next. Doing this, deletes the files associated with the replica from the target datastore and removes any corresponding replication settings for the VM at source.

Conclusion
Setting up vSphere Replication is quite easy although the deployment process can be somewhat difficult. Replication takes place at the host level. This means that vSphere Replication is storage agnostic, meaning any type of storage architecture is supported be it NAS, SAN, DAS and even vSAN. Additionally, the solution will not cost you an extra dime if you’re already running a vSphere Essentials Plus Kit, enterprise editions of vSphere and even the vCloud suite. It goes without saying, that vSphere Replication should complement an existing Disaster Recovery strategy as opposed to relying solely on it.VMware vSphere Replication is a vCenter integrated solution that effectively protects your virtual machines thus complementing any DR strategy you might have in place. Since replication occurs at the host level, vSphere Replication is compatible with a number of storage architectures and technology including SAN, NAS, DAS and vSAN which makes the solution extremely versatile.
From a network perspective, replication traffic is kept in check by using compression and replicating only data that has changed. We’ve also seen that RPO can be set to anywhere from 5 minutes to 24 hours on an individual VM basis. Multiple recovery points (snapshots) and VSS quiescing ensure maximum protection for your VMs and hosted applications.