VM cannot be added to vSphere Replication/SRM

Products

• VMware Live Recovery

Issue/Introduction

This article addresses anissue where a Virtual Machine (VM) cannot be configured for vSphere Replication, thereby preventing its inclusion in a VMware Site Recovery Manager (SRM) Protection Group. Attempts to initiate replication for the VM from the primary site fail, as the VM does not appear as an available option for replication setup, or existing replication attempts continuously error out. This leads to the VM being unprotected by SRM.

Environment

• VMware Live Recovery
• VMware vSphere Replication
• VMware Site Recovery Manager (SRM)

Cause

The root cause of this problem is the presence of a stale, erroneous, or lingering replication entry for the VM on the secondary/recovery site. Even if a previous replication attempt failed or was incomplete, its metadata might persist in the vSphere Replication appliance database.

This phantom replication entry falsely registers the VM as being actively replicated or in a state of replication on the secondary side. Since vSphere Replication enforces that a VM can only have one active replication stream at a time, this stale entry prevents any new replication configurations from being initiated for the VM from the primary site. The vSphere Replication system perceives a conflict, locking the VM from further replication attempts until the old, erroneous state is cleared.

Resolution

To resolve this issue and enable successful replication and SRM protection for the VM, follow these steps:

1. Identify the Stale Replication:

   • Log in to the vCenter Server managing the secondary/recovery site.
   • Navigate to the vSphere Replication interface (often accessible via the vSphere Client menu).
   • Locate the affected VM within the list of replicated VMs or configured replications. It will likely show an error state or an incomplete status.

2. Force Remove the Stale Replication:

   • Select the VM with the stale replication entry on the secondary site.
   • Initiate a "Remove" operation and select "Force Remove". This action is crucial as it purges the corrupted or lingering replication metadata associated with the VM from the vSphere Replication database.

3. Re-create Replication from Primary Site:

   • Once the stale entry is successfully removed, navigate to the vCenter Server managing the primary/source site.
   • Initiate a new vSphere Replication configuration for the VM from scratch.
   • Ensure all replication parameters (e.g., Recovery Point Objective (RPO), target datastore, network mappings, IP customization) are correctly defined according to your disaster recovery plan.
   • Monitor the replication to ensure it initializes and progresses to a healthy "OK" state. This will take some time to replicate the data, depending on factors such as VM size.

4. Add VM to SRM Protection Group:

   • After the vSphere Replication for the VM is established and healthy, proceed to add the VM to its designated SRM Protection Group. This will ensure the VM is included in your disaster recovery plan.

Additional Information

The "Force Remove" operation on the recovery site is critical because it directly addresses the root cause: the conflicting, stale replication metadata. By clearing this erroneous entry, the VM is effectively "released" from its previous, failed replication state. This allows vSphere Replication to correctly identify the VM as available for a new replication configuration from the primary site. Re-creating the replication from scratch ensures a clean, healthy, and fully functional replication stream is established, enabling the VM to be successfully managed and protected by SRM.