- Volume group names are trimmed in the snapshot source when array replication type is changed or is disconnected. In the vSphere SRM GUI, planned failover and disaster failover will show the status of partially recovered and throw errors for volumes in vgroups, a test failover will also show warnings. This is only an issue for datastore volumes in volume groups, all other datastores are not be affected.
- 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.
-
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 --connectis 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 thepurearray connectprocess from the array that had the connection initiated from initially. - After upgrading to PureSRA 3.0, it will be necessary to disable and re-enable the array manager used by PureSRA. PureSRA 3.0 supports stretched storage so all existing array managers will need to be restarted to trigger a discover arrays operation.
- Failover and test failovers of volumes inside a volume group may fail if there is a replicated protection group with a host or host group as a member. A future release of Purity will fix this, but for now, a workaround will be to either not use volume groups, or make sure there are no replicated protection groups with hosts and host group members.
-
If volumes are in the process of being deleted during a SRM device discovery operation, the discovery can inadvertently fail. This is a known issue and will be resolved. If this occurs re-run the operation within SRM so the device discovery can be retried. This is most likely to occur in dynamic environments with vvols where VMs (and therefore their virtual volumes) are often migrated across arrays.The error will look something like:
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. - 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.
- After installing the SRA to the Linux SRM Server an error that the SRA Upload failed may appear. There is a issue with the SRM Server that after the SRA has installed the SRM browser session is closed. The SRA should show up as installed after refreshing the SRM page.