Hi Keith, That's correct, as of RP 4.1.2 and XtremIO 4.0, the replica volumes will remain accessible so caution must be taken if continuously accessing the replica volume (This matter is widely mitigated by the fact that the snaps on the target XIO array are private to the user which RP uses and tech). If SRM with RP SRA is managing Test and Failover recovery tasks then just make sure to use SRM which will guarantee the DSs are used after image access has been executed. If accessing the target datasores directly then make sure to manually enter image access (after disabling SRM external management) or even better unmount datastores if they aren't needed. You are right in saying that SRM cannot map the replica volumes as they need to be mapped to the ESXs on the replica side.  Additionally, in the near future we are planning to introduce the capability to put the replica volumes in NoAccess device state while not in image access.  Regards, Idan Kentor RecoverPoint Corporate Systems Engineering idan.kentor[NAME].com
Hi,  Just curious what people might be doing out there or what the messaging is around using RecoverPoint with SRM, but having the underlying arrays be XtremIO (specifically the target). Utilizing snapshot shipping, the replica devices are not "WD" or "No Access" as they typically are with the other splitters and this means that leaving them mapped and provisioned to the target ESX clusters for VMware SRM purposes adds a little more complexity or knowledge around knowing not to touch them. Unmapping them outside of SRM testing is likely not going to be an option since it defeats some of the purpose of DR automation with SRM, but wasn't sure what people are seeing as the preferred approach?  thanks!
VMware SRM with RecoverPoint and XtremIO