Known Issues and Best Practices

Release Notes for VMware Solutions
Audience
Public
Content Type
Release Notes
Technology Integrations
VMware
Source Type
Documentation

  1. When configuring your FlashArray Protection Groups to be used with SRM, please ensure that the Retention Policy is configured to retain at minimum 1 snapshot for 1 day. This is important as the SRA will be leveraging the replication retention policy when taking test, failover and re-protect array based snapshots. For Example: 
    
# purepgroup list --retention
Name                                         Array   All For  Per Day  Days
sn1-405-c12-25:sn1-405-25-prod-pgroup-1      source  1d       4        7
                                             target  2h       1        1
  2. Whenever an array's replication type is changed, or an array loses its connection to replicating arrays, volume group names are trimmed in the snapshot source (as displayed by the CLI purevol list --snap command, for example).
  3. If either FlashArray has been renamed after they have been connected, all test failovers, failovers and reprotects will not execute completely. The is due to the array pair naming not getting updated if either array is renamed (if purearray list --connect is ran from the CLI, the previous names will show). Should an array be renamed, the recommend remediation if using only async replication is to disconnect the FlashArrays and reconnect them. Should ActiveCluster be enabled, the recommended remediation is to run through the purearray connect process from the array that had the connection initiated from initially.
  4. For volumes in vgroups, planned failover and disaster failover show the status partially recovered in the vSphere SRM GUI, with an error message. A test failover also displays warnings. This is only an issue for datastore volumes in volume groups; all other datastores are not affected. To successfully recover, remove any SRM-controlled volumes from volume groups.
  5. For SRM protection groups configured with FlashArray Volumes in Volume Groups the SRM protection group/recovery plan will no longer work if volumes have been moved out of a volume group, volume group names have changed or volumes were moved to a new volume group.
  6. Device Discovery, DR Failover and test failovers of volumes inside a Volume Group (VG) may fail if there is a replicated Protection Group with a host or host group as a member that is also connected to the volume in the VG. We expect a future release of Purity to fix this issue. Until then, the workaround is either to not use Volume Groups, or to ensure there are no replicated Protection Groups with hosts and host group members.
  7. When using ActiveCluster with SRM, ensure the personality for all Purity hosts connecting to ESXi servers is set to esxi. Failure to do so may cause datastores backed by ActiveCluster stretched pods to become inaccessible after an interruption to the stretched storage connection.
  8. After upgrading to PureSRA 3.0, it is necessary to disable and re-enable the array manager used by PureSRA. Because PureSRA 3.0 supports stretched storage, all existing array managers must be restarted to trigger a discover arrays operation.
  9. Test failovers of Volumes, Volume Group Volumes or Pod Volumes are expected to fail if the character length of the volume name exceeds 42 characters. If the volume name exceeds 42 characters, then during the test failover when the volume is renamed with the "-puresra-testFailover" suffix, the volume name will exceed 63 characters and the test failover will fail. At this time Pure's recommendations to avoid this from occurring, ensure that your Volume Names do not exceed 42 characters.
  10. If volumes are in the process of being deleted during a vSphere SRM device discovery operation, the discovery can fail. This is a known issue that we expect to resolve in a future release. If this occurs, re-run the operation within vSphere SRM so that the device discovery can be retried. This issue is most likely to occur in dynamic environments with VVols where VMs (and therefore also their virtual volumes) are often migrated across arrays.The following is an example error message: 
    
ERROR!
649 com.vmware.vim.binding.dr.storage.fault.CommandFailed: SRA command 'discoverDevices' failed. Array operation failed: "PureRestException: HttpStatusCode = 'BadRequest', RestErrorCode = 'NotExist', Details = '["msg":"Volume does not exist.","ctx":"pod1::sync-vmfs"]', InnerException = 'System.Net.WebException: The remote server returned an error: (400) Bad Request.
  11. When using ActiveCluster with SRM, if the Stretched Pods are in a state of Resyncing, the device discovery will fail. You will need to run the device discovery once all stretched pods are in sync.
  12. When using ActiveCluster with SRM, when testing a Recovery Plan, the test can fail if the [pod_name::volume_name]-testFailoverStart exceeds 42 characters. The failure will note that the volume was unable to be created.