In parts 1 and 2 we focused on setting up the prerequisites for protecting a VM using SRM, namely configuring replication and adding the VM to a protection group. In part 3 the focus will be on configuring the protection of the VM in SRM and creating a Recovery Plan.
This post is going to be fairly brief as the SRM plugin for vRO will do most of the hard work for us, leaving only a small amount of custom coding.
Configuring Protection for the VM
Whilst we added our VM to an SRM Protection Group in part 2, it is still in an Unprotected state. This means there is no placeholder VM present at the Recovery Site and the resource mappings to use during a recovery have not been set.
Configuring protection requires us to confirm whether we want to customise the resource mappings for our VM, or simply use the default values the administrator has configured. In the SRM web console there is a Configure Protection button to complete this process, in the vRO plugin there is a workflow called Protect Virtual Machine to achieve this.
The workflow can be found in the Library>SRM>Protection Groups folder within the vRO inventory. Checking the inputs tab we see it needs two pieces of information
- The SRM Protection Group
- The Virtual Machine
Both of these values are already known to us. We have the Virtual Machine object as an output from the Configure Replication workflow we created in part 1. While the Protection Group is available as an output of the Create a Protection Group and Add a VM workflow we created in part 2.
Create a Recovery Plan
Now the VM is protected and a placeholder VM has been created based on the resource mappings at the Recovery Site we need to create a Recovery Plan to enable SRM to fail over the VM.
The SRM plugin again provides us with a simple workflow to complete this activity, this time the workflow is called Create Recovery Plan and it is in the Library>SRM>Recovery Plans folder. As a bonus this workflow will take care of adding the Protection Group to the Recovery Plan once it is created as well, so we don’t need a separate workflow to perform that step.
The workflow has four inputs
- The SRM Recovery Folder
- The name to use for the plan
- The description to use for the plan
- The SRM Protection Groups to add to the plan
For the plan name I am going to reuse the name of the Protection Group for simplicity, and predefine the description value as Created via vRO just as I did in part 2 for the Protection Group.
As we know the Protection Group value is available to us from the workflow we created in part 2, but we haven’t had to use the SRM:RecoveryFolder object before. Looking up the object on my favourite site vroapi.com we see that it is returned by the getRecoveryRootFolder() method on the SRM:Site object. The SRM:Site is a value we have from the workflow we created in part 1, it is the localSite value so we have everything we need to construct our workflow.
The workflow structure
Just as I did for parts 1 and 2 I am creating a new workflow, and will add it to my parent Configure DR for the VM workflow so that is is executed as part of the same event broker subscription as the earlier steps.
The workflow will have the following input parameters:
- localSRMSite
- vm
- protectionGroup
and one output parameter to represent the new Recovery Plan it creates:
- recoveryPlan
The first step in the workflow will be the Protect Virtual Machine workflow, which will have the vm and protectionGroup inputs mapped. This workflow doesn’t provide any outputs so there isn’t anything else to configure.
Next I’m adding an action to retrieve the SRM:RecoveryFolder. The code is almost identical to the action used in part 2, and I’ve mapped the value it returns to a new attribute called recoveryFolder.
After the action I’ve added a scripting element to convert the protectionGroup value into an array, as this is the format required for the next step which is the Create Recovery Plan workflow. I’m also retrieving the name property from the protectionGroup to use as the name of the Recovery Plan.
So the overall workflow looks like this
And our parent workflow nows looks like this
With the following input and output mappings for the new subworkflow
That’s it for part 3. In part 4 the focus will be on configuring the recovery settings for the VM inside our new Recovery Plan.