Troubleshooting SRM when using vVols replication

The workflow within SRM is significantly different when using vVols replication from what is used with SRA and traditional datastores. For example, there is no array manager concept. As such, discoverarrays and discoverdevices commands are never seen.

When troubleshooting, it is beneficial to understand the new workflows, which are listed below:

  1. queryReplicationPeer: Discovers the replication agreements between two fault domains.

  2. queryFaultDomain: Discovers fault domain hierarchy.

  3. queryReplicationGroup: Discovers the replication groups present in the source or target domains.

  4. syncReplicationGroup: Synchronizes the data between source and target.

  5. queryPointInTimeReplica: Discovers the point in time replicas on a target.

  6. testFailoverReplicationGroupStart: Begins test failover.

  7. testFailoverReplicationGroupStop: Ends test failover.

  8. promoteReplicationGroup: Promotes a group currently in test to production.

  9. prepareFailoverReplicationGroup: Prepares for a disaster recovery.

  10. failoverReplicationGroup: Executes disaster recovery.

  11. reverseReplicateGroup: Initiates reverse replication.

  12. queryMatchingContainer: Finds containers (along with Hosts or Replication Groups) that might satisfy a provisioning request with a given policy.

  13. queryResourceMetadata: Discovers the metadata of all resources from the VASA provider, the resource utilization can be returned as an answer to the queryMatchingContainer function.

The most common error seen when configuring vVols replication is a failure to discover the SnapMirror relationships. This occurs because the volumes and SnapMirror relationships are created outside of the purview of ONTAP Tools. Therefore, it is a best practice to always make sure your SnapMirror relationship is fully initialized and that you have run a rediscovery in ONTAP Tools at both sites before attempting to create a replicated vVols datastore.