Now that all of the prerequisites are complete, it is time to start creating protection groups and recovery plans.

This is part 3 of this series, the earlier parts were:

• Site Recovery Manager and ActiveCluster Part I: Pre-SRM Configuration
• Site Recovery Manager and ActiveCluster Part II: Configuring SRM

In SRM, there are two main management objects. Protection groups and recovery plans.

Protection groups are a selection of VMs (or datastores) that will always be failed over in unison. A VM or datastore can only be in one protection group.

A recovery plan includes one or more protection groups. A recovery plan indicates VM boot order, scripts or custom steps, IP changes and other time-of-failover configurations. A protection group can be in one or more recovery plans.

Creating a protection group

To create a protection group (I will refer to as PGs from now on), click on the Protection Group tab and then the NEW button.

Give your new PG a name and description and then a direction–if the VMs are currently on a certain vCenter, choose that one as the source.

Click Next.

Now choose storage policies. Active-Active storage is only supported in SRM with storage policy protection groups (SPPGs).

Click Next.

Choose your storage policy, mine is called srm-420-405-ActiveCluster.

Click Next.

On the next screen I am going to choose “Do not add to a recovery plan” but feel free to do that if you want. I will do it later in this post though.

Click Next then Finish.

To look at your protection group, click on the Protection Groups tab and then your new protection group. Verify that all of the VMs you want to be in the group are there. If some are missing, you likely have forgotten to apply the storage policy to it (or it has been mistakenly removed).

One column under the VM listing that is of interest is the “vMotion Eligible”. In order for this to be “yes” the following requirements exist:

• The PG must be a storage policy one
• The VM must be on stretched storage (like ActiveCluster)
• The VM must be powered-on

Why does this matter? Well in a stretched storage environment, SRM has the ability to actually vMotion the VMs on that type of storage from one vCenter to the other–therefore eliminating any downtime for those VMs during failover. This is a major benefit of SRM stretched storage support. More on this in an upcoming blog post.

Beyond looking at things, there is no much to DO in the PG, the work is all in the recovery plan. So let’s create one and see what’s available.

Creating a Recovery Plan

The next step is to create a recovery plan (which I will call RP from now on). Click on recovery plans and then the NEW button.

Give the RP a name and description and then choose the same direction as your PG.

Click Next.

Then choose the radio button for Storage policy protection groups and choose the PG(s) you want to add.

Click Next.

If you want to override network mappings for test failovers you can configure that here, otherwise click Next and then Finish. You can always change that later.

Now that the RP is created, click on it to view and/or edit it.

I am not going to go into everything in recovery plans here, but I will mention one thing. If my VMs is vMotion eligible, can I change that?

Yes! In the recovery plan. If you click on the Virtual Machines tab, you will see your VMs. Click on one and then choose the configure recovery button up top.

There is an option in here to override vMotion attempts. If you signal (during a failover) that SRM should attempt vMotion, it will try to vMotion all eligible VMs. If there are VMs that you do not want to be vMotioned, even though they are eligible, you can go in here to make them not eligible.

Deselecting the vMotion option will force the VM to always just be powered down, unregistered and then registered and booted up on the other vCenter instead of vMotioned.

That’s it for part III. In the next posts, I will do a FAQ and also walk through the recovery process and test recovery process.