Ghost Array Pairs visible in Site Recovery Manager (SRM) or VMware Live Recovery.

Products

• VMware Live Recovery

Issue/Introduction

Users may observe "ghost" or unexpected array pairs listed at the Site within VMware Live Recovery (formerly Site Recovery Manager).

Symptoms:

• Multiple ghost array pairs appear in the Array Pairs tab of the SRM interface. Green check mark is valid pair, while the others are not.
  
  

• The issue is persistent across discovery cycles and is not caused by a product upgrade, as the symptoms may be present in earlier versions.

• The SRM Database (SRM DB) does not contain these entries when queried via the SrmDbTool utility.

Environment

 

• VMware Live Recovery / Site Recovery Manager (SRM)

• Adapter: NetApp Storage Replication Adapter (SRA)

 

Cause

The issue is not a software regression or database corruption within SRM. Instead, it is caused by stale metadata returned by the Storage Replication Adapter (SRA) during the discoverArrays workflow.

SRM acts as a passive manager during array discovery. It requests information from the SRA, which in turn queries the storage controllers. If the SRA's XML response contains legacy or uninitialized peer relationships existing on the storage array, SRM is required to display them in the User Interface.

Verification via Logs: The vmware-dr.log confirms that the SRA explicitly reports these ghost peers in its XML output, both before and after any version changes:

2026-02-04T02:06:54.357-05:00 verbose vmware-dr[02525] [SRM@6876 sub=SraCommand opID=660a02e5-####-####-####-###########-reloadAdapters:] discoverArrays responded with:
--> <?xml version="1.0" encoding="UTF-8"?><Response xmlns="http://www.vmware.com/srm/sra/v2" xmlns:replication="http://www.vmware.com/srm/sra30" xmlns:foo="http://www.foo.com/sra/v2">
-->
-->         <Arrays>
-->             <Array id="SiteA_ArrayID:datastore_name">
-->                 <Model>
-->                     <Name>#####</Name>
-->                     <Vendor>#####</Vendor>
-->                 </Model>
-->                 <PeerArrays>
-->                     <PeerArray id="Site_B_ArrayId:datastore_name"></PeerArray>
-->                     <PeerArray id="Site_B_ArrayId:datastore_name_1"></PeerArray>
-->                 </PeerArrays>
-->                 .
                    .
-->             </Array>
-->         </Arrays>

SRM will display both the Site_B array pair with the Site A array even though the array pair won't exist. Since the SRA's XML response contains the array manager information. SRM will display the information in the UI.

Resolution

Because SRM accurately reflects data provided by the storage layer via the SRA, the cleanup must occur at the storage level.

1. Identify Stale Relationships: Coordinate with your Storage Administration team to identify stale or uninitialized peer array entries within the storage cluster.

2. Storage Layer Cleanup: Remove the stale metadata directly from the storage controllers.

3. Refresh SRM Discovery: Once the storage configuration is cleaned:

   • Navigate to Array Pairs in the SRM/Live Recovery UI.

   • Select the affected Storage Replication Adapter.

   • Click Discover Arrays.

   • Confirm that the ghost pairs no longer appear, as the SRA will no longer include them in the XML response.

Additional Information

 

• Validation Tool: Use /opt/vmware/srm/dbtool/SrmDbTool.py Query ArrayPair to confirm the SRM database does not hold these records internally. If the SRM DB hold the stale record then use the KB: Cannot remove an Array Pair from within VLSR Recovery UI. to remove the stale entries.