VMware announced Site Recovery Manager version 6.1 this week at VMworld in San Francisco California. Several new features were unveiled for VMware’s flagship Disaster Recovery product.

Storage Profile Protection Groups

Remember back in the old days (prior to today), when deploying a new virtual machine we had to ensure the datastore we were putting the virtual machine on was replicated? Not only that, but if this new VM was part of a group of similar VMs that needed to fail over together, we needed to make sure it was in the same protection group? Well VMware decided this was a cumbersome process and added “Storage Profile Protection Groups”.

In SRM 6.1 we will use storage profiles to map datastores with protection groups. Now we’ll be able to deploy a VM and select a storage profile to automatically place the VM in the correct datastore and even better, configure protection for the virtual machine.

Orchestrated vMotion in Active-Active Datacenters

Yeah, you kind of expected something like this right? VMware announced long distance vMotion and cross vCenter vMotions with vSphere 6.0 last VMworld. We can now start doing live migrations between physical locations so why not add this to the disaster recovery orchestration engine?

I think this new feature might be very useful for some companies that routinely deal with disasters where there is some warning, like a hurricane. Prior to SRM 6.1 you would have been able to do a planned failover through a previous version of SRM, but it would have required a small amount of downtime. You might also have been able to do a long distance vMotion but this would have been some manual or scripted work. With SRM 6.1 the planned failover could be done in an orchestrated fashion with zero downtime!

OK, you’ve probably got some questions about this, lets see if I can knock out a few of them.

Question 1: What if my virtual machine has a lot of RAM and vMotions could take a very long time? Do I have to vMotion them for planned migrations?

Answer 1: Nope! If you have certain VMs that you know you never want to vMotion during your planned migration, you’ll have the option to select the VM and disable the vMotion option during protection.

Question 2: What about the network?

Answer 2: Yeah, the network needs to be the same on both vCenters or your VM won’t be able to communicate with the rest of the network anymore. This is the same as a normal vMotion. SRM will be able to change IP Addresses like it always has, but this requires a small amount of downtime as you might guess.

Question 3: Do I have two different planned recovery options then?

Answer 3: There is one planned recovery still, but now there is an option to enable the vMotion of eligible VMs.

vCenter Spanned NSX Integration

The last main feature of the product is its integration with the NSX product. You used to have to explicitly map each VM with a recovery network. Now in SRM 6.1 if you’re using NSX on both vCenters and the NSX networks are the same on each, SRM will map these networks for you. (yes, you can override this mapping if you need).

Other Notes

SRM 6.1 has also done some rearranging of the recovery plans so that you can get better visibility into what is going on during a failure. If you’ve ever had to troubleshoot a failover this is a great addition to help narrow down the problem. It also provides more places to but scripts into your failover, which is welcomed.