I recently was at a site where we installed SRM to fail to a DR site a few miles down the road. A few weeks prior to installing, we updated all of the ESX hosts from v3.0 to v3.5 U3. Once we replicated storage, and installed SRM, we tested successfully with a few selected VMs, failing over from the protected site to the recovery site. We then had to login and change IPs manually to connect to the network. This validated that the VMs would fail over as expected.
Once we accomplished that, we then configured the batch IP tool to change the IPs of the test VMs to the correct network automatically. To our surprise, our next test failed miserably! After several attempts, the recovery would not complete and we were at a loss to find a solution.
After several attempts, and a night off to tip a few pints and think about it, I came in the next day and checked something that was bothering me. Come to find out that the test VMs had not had vmtools updated to v3.5, and were complaining that they were not up to date. After updating vmtools, and allowing for replication of the changes to occur, we tested again. As if magic, the IPs changed, and the test was successful. A full failover of the VM was accomplished, and the project was able to move over to the next phase.
As a note to all of you planning to implement SRM, make sure that vmtools is up to date on all of your VMs before attempting a failover with IP changes!
"There are 10 types of people. Those who understand binary and those who don't."
-Tim Antonowicz @timantz
VCDX 112
