SRM Protection Group: Error: Placeholder Create Error after LUN or Datastore recreation
search cancel

SRM Protection Group: Error: Placeholder Create Error after LUN or Datastore recreation

book

Article ID: 444698

calendar_today

Updated On:

Products

VMware Live Recovery

Issue/Introduction

Symptoms

Creating or reconfiguring an SRM Protection Group fails with the following error:

Placeholder Create Error: The object 'vim.Datastore:[UUID_1]:[MOREF_1]' has already been deleted or has not been completely created

Additional symptoms include:

  • Protection Group status stuck at 57% or showing as "Not Configured."
  • Errors in vmware-dr.log indicating: (vmodl.fault.ManagedObjectNotFound) for specific datastore MoRefs.
  • Issues often occur after a decommissioned storage array leaves stale replication components or when a LUN is recreated with the same name but a new MoRef ID.

Environment

  • VMware Live Recovery (SRM) 9.0.x, 9.1.x
  • vSphere Replication 8.x, 9.x

Cause

When a LUN or datastore is deleted and recreated, vCenter assigns it a new Managed Object Reference (MoRef) ID. SRM retains the original MoRef ID in its database. Additionally, a known limitation in the 32-bit integer architecture of the SRM database can cause ID numbers in the pdr_vmrecoverysettings table to reach their maximum limit, preventing new placeholder creation.

Resolution

Fixed in VMware Live Recovery 9.x and higher. See  for steps to download this release.

Procedure to Refresh Mappings

  1. Log in to the Site Recovery UI.
  2. Navigate to Site Pairs > [Your Site Pair] > Configure.
  3. Select Placeholder Mappings.
  4. Locate the stale mapping for the affected cluster/datastore.
  5. Remove the existing stale mapping.
  6. Click New to create a new mapping selecting the recreated datastore.
  7. Search for orphaned placeholder VMs at the Recovery Site and select Remove from Inventory.
  8. Restart the Site Recovery Manager (vmware-dr) service via the VAMI at https://<IP>:5480.

If the issue persists due to the 32-bit integer limit, the SRM database must be reset. For detailed assistance or specific database cleanup using LDAP utilities, see .

Additional Information