Error: "Failed to demote source consistency group 'CG_Name'. SRA command 'prepareFailover' failed for consistency group 'CG_Name'. An unexpected error occurred in SRA. Please check EmcSrdfSra log file for more information on the error.

Products

• VMware Live Recovery

Issue/Introduction

Symptoms:

• Following errors are noticed during planned recovery.

Error - Failed to demote source consistency group 'CG_NAME'. SRA command 'prepareFailover' failed for consistency group 'CG_NAME'. An unexpected error occurred in SRA. Please check EmcSrdfSra log file for more information on the error.

Error:    SRA command 'prepareFailover' failed for consistency group 'CG_NAME'. An unexpected error occurred in SRA. Please check EmcSrdfSra log file for more information on the error.

 

Environment

• VMware Site Recovery Manager 8.x
• VMware Site Recovery Manager 9.x

Cause

• The SRM planned migration failed because the underlying SRDF pair state is out of sync with what the Storage Replication Adapter (SRA) expects during a planned migration.
  
  
• Log analysis from the SRA logs located at /opt/vmware/support/logs/SRA/sha-***/EmcSrdfSra.log revealed a backtrace and error message "[ERROR]: The Symm Dev [######] on Symm [#########] is in [Split] state. The adapter cannot proceed with devices in [Split] state. Exiting" which confirmed that the replication link between the source and target arrays for that specific device is manually severed or disconnected.
  
  
• The following log entries illustrate the issue:

[20251225165438 15606   224 [email protected]] The state of Symm Dev [####] on Symm [##########] is [Ready]
[20251225165438 15606   239 [email protected]] Checking if device has a 3-site config
[20251225165438 15606   346 [email protected]] The Symm Dev [#####] on Symm [###########] is present in [1] DGs [CG_NAME]
[20251225165438 15606   386 [email protected]] The Symm Dev [####] on Symm [############] is present in [0] CGs []
[20251225165438 15606   744 [email protected]] Symm Dev [######]   RDF Group [80]   CG [N/A]   DG [DG_NAME]
.
.
[20251225165438 15606  2055 [email protected]] Performing SymDgShow() on Group Name: CG_NAME
[20251225165438 15606  2088 [email protected]] Iterating each input device to determine and verify RDF mode, RDF/Device consistency, RDF type and RDF state
[20251225165438 15606  2144 [email protected]] RDF type of Symm Dev [######] is [R1]
[20251225165438 15606  2215 [email protected]] Checking if Symm Dev [######] is in [Split] state
[20251225165438 15606  2239 [email protected]] [ERROR]: The Symm Dev [######] on Symm [##########] is in [Split] state. The adapter cannot proceed with devices in [Split] state. Exiting
[20251225165438 15606   344 setMarker                       ] _______Backtrace begin_______
[20251225165438 15606  2030 [email protected]] Enter
[20251225165438 15606  2031 [email protected]] Validating input devices
[20251225165438 15606  2055 [email protected]] Performing SymDgShow() on Group Name: CG_NAME
[20251225165438 15606  2088 [email protected]] Iterating each input device to determine and verify RDF mode, RDF/Device consistency, RDF type and RDF state
[20251225165438 15606  2144 [email protected]] RDF type of Symm Dev [######] is [R1]
[20251225165438 15606  2215 [email protected]] Checking if Symm Dev [######] is in [Split] state
[20251225165438 15606   344 setMarker                       ] _______Backtrace end_______
[20251225165438 15606  4132 [email protected]         ] [ERROR]: Input device validation succeeded but one/many of the adapter's conditions is not met. Exiting with failure

Breakdown of the logs.

1. 1. 1. Consistency Group vs. Device Group: The log shows the device is in Device Group (DG), but it shows CG [N/A]. This means the SRA is looking at a SymCLI Device Group rather than a hardware-level Consistency Group.

      2. Ready State: The device status is [Ready], meaning the LUN is accessible to the ESXi hosts, but the RDF link status is Split.

      3. Planned Migration Logic: In a planned migration, SRM must ensure no data loss. If the link is "Split," the SRA cannot verify if the R2 (target) side is up-to-date with the R1 (source) side. It aborts to prevent a "dirty" failover. Since in a Planned Migration, SRM expects the storage to be in a healthy, replicated state (usually Synchronized or Consistent). When SRM issues the prepareFailover command, it attempts to:

1. 1. 1. 1. Make the source side Read-Only.

         2. Perform a final sync to the target.

         3. Demote the source devices.

Because the device is already in a Split state, the SRA cannot perform these operations. It treats the "Split" status as an "unexpected state" because it can't guarantee data consistency if the link isn't active at the moment the migration starts.

Resolution

• Recommended to bring the SRDF pair back into a valid state before SRM can manage it.

Common reasons for a "Split" state include:

• • • Manual Intervention: Someone manually split the pairs using SYMCLI or Unisphere to perform testing or manual backups.

    • Previous Failed Run: A previous attempt at a Recovery Plan might have partially executed and left the devices in a transitional state.

    • Link Issues: Connectivity problems between the arrays might have forced the pair into a failed or split state.

• User need to check the SRDF pair state from the storage side and move the pair from Split to Synchronized. Verify Consistency Group Health as the error. All devices within the concerned consistency group must be in a replicated state (Synchronized/Consistent). If even one device is "Split," the whole SRA command will fail.

Once the storage layer reports the pairs as Synchronized:

• • • Go to the SRM interface.

    • Go to Storage Replication Adapters and click Rescan Adapters.

    • Go to Array Pairs and click Refresh.