The most frequent question I have had as of late is what SRA supports the new SRM 8.1. It’s this one. With that of course comes vSphere 6.7. Here is the whole table from the RN which I’ve made unnaturally large so you can see it better. Note there is one mistake in here which will be corrected shortly. We have a footnote that says PowerMax OS is only supported on PowerMax arrays but that should have been removed since you can run PowerMax OS on VMAX All Flash. Can’t catch everything. Also vSphere 6.5 U2 just came out so it was not possible to test and include in this table. ESXi patches for compatible versions of vSphere don’t break our SRA so if you are at that version, don’t be concerned.
As I’ve said many times before, VMware certification isn’t always a quick process so there is the possibility if you check on VMware’s site it will not show the compatibility yet. Rest assured it will be there shortly.
So besides new version support, there are two big features in SRDF SRA 9.0. The first is the ability to test in a disconnected state. VMware SRM has offered this for a few versions but each vendor must enable it in their SRA. It’s not a simple change or we would have done it earlier. Before this version of the SRA, we needed to communicate with Solutions Enabler at both sites during a test. In addition, the SRDF pairs had to be in the proper state. This new capability doesn’t necessarily require an additional setting in the global options file, however depending on the state of the SRDF pairs, it may be necessary to set TestFailoverForce to yes.
The second feature is the first step on the way to remove the reliance on the XML files we use in the SRM testing. Using two new parameters in the global options file,
the SRA will create the snapshot target devices for the user at the time of the test. No longer do you have to pre-create devices and match them to the R2 devices in the testfailover XML file. Simply set the autotargetdevice to yes, decide whether to reuse the devices for future tests (otherwise the SRA will delete them after the test), and run your test. In addition, though we default to putting the new devices in the R2 storage group, we can use whatever storage group you want us to.
*** Update 8-20-2018
BTW the ability of the SRA to create target devices has NO bearing whatsoever on the requirement to create device/composite/consistency groups for the R1 and R2 devices. Whether you create the target devices or the SRA does, the R1 and R2 groups need to be recognized by SRM when the devices are discovered. The requirement for the groups is clearly explained in the TechBook.
I created a demo of the functionality you can watch here. I’ve chosen to delete the devices during cleanup so you can see them removed from the storage group and array.
The new functionality does not prevent the user from running a test with the existing functionality where the snapshot targets are manually created and the XML file updated. I suspect some storage admins will not want the SRA creating devices and that’s perfectly fine. Another use case might be where customers use very large datastores and they already have target devices set aside for the SRM testing. In that circumstance it wouldn’t make sense to recreate.
Note that the use of AutoTargetDevice is not supported with GNS.