I am trying to figure out the options for testing SRM. I know that I can perform a test failover (to test bubble network) when the WAN is up and both SRM instances can talk to eachother. What if I wanted to disconnect the WAN and execute a test failover? Will SRM let me do a test failover if the protected site is offline? The thinking is that if the disconnecting of the WAN is a requirement for SRM testing, that I would still like to do a test failover as a real failover would be a mess to cleanup when it is a test.
Although I have not done this myself, my thinking is that the "Test" does not care if you have the connection to Recovery Site as part of the process is to isolate the Recovery VMs Networking and Storage to bring them up. The only part I think it may look to use the connection is for the option to replicate recent changes to the VMs. For your test, you can uncheck this box.
Good Luck !
This is still an issue that needs to be addressed. We recently did a DR test and we have several applications that are physical and we have to test their actual operation together with the VMs as part of the test. These are legacy applications that can't change names or IPs, so to not impact production we sever the line between the DR site and the Datacenter. SRM cannot do a test failover in a disconnected state. The only option we had, was to browse the datastores and manually import hundreds of VMs. I even brought this up to the experts at VMworld and they were at a loss. Their answer was that SRM is designed to test the operational state of the server, not the application so why would you ever want your VMs to talk to anything?
Our management is pressing us to use other solutions, I'd like to stay with SRM but if it can't serve our needs we'll have to switch.
FTR, I was able to perform an SRM failover in test mode with the WAN connection down using vSphere Replication. I have not tested it with Array based replication yet.
What array based replication and SRM version are you using?
As for the legacy applications, if they can't change IP between sites and the other site is using a unique IP subnet how do you planning on failing it over during a real failover? We had a similar situation with an app that was hard coded, though the app was in a VM. We worked with the developer and created an additional instance in the recovery site using the DR site's IP subnet. That way it can be tested without having to fail it over and make code changes during DR or DR test..
We're using EMCs RPA and SRM 188.8.131.523. We have dedicated subnets with the same VLAN ids at the DR site. In the event of a failure at the primary site, we just bring up the old network at the DR site.
SRM supports disconnected tests if this is supported by the underlying replication technology (in fact in the SRM UI if we detect the sites are severed we disable the replicate recent changes box). For vSphere Replication and many storage replication technologies this will work fine, I know for some SRAs there may be some configuration options you need to set to enable this. I would recommend you speak with your storage replication vendor about whether they support this capability in their SRA and whether there are any specific configuration options required to enable it.
I received the following response from EMC when I opened a case about the SRA.
Please be informed we can do a failover when the WAN link is severed, but we need to change an option before do it. Kindly follow the steps mentioned below to change the option which enables this feature:
I installed the following plug-ins from their website:
General Management: emc-vsi-sv-5.6.3-vmware-vsphere-WINDOWS-x86.exe
After adding the RecoverPoint appliances, I clicked AllowTestFailover. I disconnected the NIC on the SRM server at our primary site and was able to run a SRM test failover in a disconnected state. We're planning to test further, but this seems to be the piece we were missing.
Just to add, starting from SRM 6.5, support for Test Recovery operation when the protected and recovery sites are disconnected is also supported through public API - see VMware Site Recovery Manager 6.5 Release Notes