In my work environment, I have a lot of Array Based Replication, almost all of it in fact.
The best practice for ABR is to isolate SRM VMs to ONLY SRM datastores.
This helps other people from moving things in and out of that datastore at will AND SRM will warn you if you have unconfigured VMs mixed with protected VMs in a protection group.
Being that I added SRM to a brownfield environment that already had replication going, re-shuffling the VMs would be a a big pain. I also had some tight deadlines. I made the decision to NOT re-shuffle at this time to isolate the SRM VMs and to plan that after everything is up and running.
One things that I found out is that SRM WILL NOT let you run a Recovery Plan in TEST mode if you have a mix of protected/non-protected VMs. This occurs because the test is to ensure that an actual recover would occur (either planned or in a disaster). In a planned recovery, SRM wants to gracefully shut down the VMs at the source side and unmount the datastores. If there is a non-protected VM on the protected datastore, it will error out because it cannot unmount the datastore. In a DR (which I care about the most), it will still try to shut down and unmount but you can force it to just work on the recovery side.
Here’s an image of the TEST mode of a recovery plan that has a VM that is not protected.
The Workaround – NOTE NOT SUPPORTED!
In my last post, I described my issue where I could not pair two sites. The issue that caused it was that the service account that SRM is configured to use at the connection account to vCenter DID NOT have permissions to SRM (it did not inherit the permissions from the root of vCenter). This can be fixed by fixing the database. What I found is that you can also go to the Permissions tab of SRM and add the permissions there as well.
I fixed my prod instance, but in my lab instance I still had the same issue. The service account did not have permissions to the protected side. I ran a TEST of a recovery plan and it SKIPPED the step to validate if there un-protected VMs and continuted to mount the storage and power-on the VMs!
The first time I ran this, I noticed that the there was no “cleanup” option for the recovery plan, even though it look like it completed.
I believe I re-ran the test and it switched to completed and showed the “cleanup” option. You can also just re-add the service account to that it has access at that point.
What this Means:
If for some reason you are using ABR and do not have pristine datastores (don’t want to clean up, cleaning up later, or someone dropped a random VM on the datastore), then you can still test the recovery plan. This will save me huge amounts of effort. I was planning on either temporarily configuring the unconfigured VMs during tests or migrating the VM to a special “Test” datastore which would cause issues with some backups.
Reminder that this is NOT SUPPORTED! I have talked to the SRM PMs to allow for a forced test failover, but I am not sure if other people really want this as well.