Recently I was given a requirement to enhance a vRO workflow which added a VM to disaster Recovery policy in SRM. The existing workflow by default added all VMs added to Priority 3 (normal) start up order. My requirement was to allow the user to specify the start up order.
Having a quick look at the environment, I could see that the SRM plugin was used so felt this was a good start – however it soon became apparent that it wasn’t ideal for me given that the information we can get out of the plugin is limited never mind having to manipulate that data. Looking online , it seemed that using PowerShell was the common answer to automating this, but I also had a constraint of not introducing any new plugins. During my online hunt I found the SRM 6.5 API guide and this became a nice resource. By browsing this API guide it became apparent that SOAP API was my only option and I continued to refer to this guide in order to find a solution – https://www.vmware.com/support/developer/srm-api/site-recovery-manager-65-api.pdf.
I decided to write this blog because there seemed a sever lack of info on using SOAP for SRM.
Creating the Workflow
Ok, so onto vRO and first things first, what do I need to do? Set the priority of course! Ok that’s fine but I have never used SOAP API before so where do I really start! I explored the existing workflows and found that there was a Workflow to remove a Virtual Machine from a DR policy – so this helped me. It taught me that using SOAP we need to first login to our target! Seems obvious right!
Ok so now I am logged into SRM – what now! A quick read of the API guide and it seemed easy. I “just” need to set the recovery settings for the VM in question with the new priority. But to set the recovery settings I had to get current settings of the recovery plan. To get the current settings of the recovery plan I need to know the recovery plan ID. To get the recovery Plan ID, I need to know the associated protection group ID. Not so easy after all.
As part of the existing Workflow , the Protection Group to add the VM too is an input from the customer based on a drop down list. In order to make this meaningful to help me I had to get the ID from this. I also found the SOAP plugin in vRO allows you to generate a Workflow based on an operation and this WF then gave me the format of the values I needed to use for each operation. This became a massive help to me and I used it quite alot
Get Protection Group ID
So, referring to the API guide I can see that I can use the “ListProtectionGroups” operation. I ran the above workflow and this gave me the format that I need to list the protection groups. Once I had the groups as part of the response, I could match the name to the customer input to ensure I get ID of the relevant group.
Get Recovery Plan ID
Next, I need to get the Recovery Plan ID. I could do this in a similar way to the above, but this time setting the protection group ID as an in parameter. As it is a 1:1 relationship then its easy to pull the plan ID.
Get Recovery Settings
Ok, so now we where getting somewhere. I have the Recovery Plan ID. I also have the VM ID from part of the existing workflow. Therefore I could now get the recovery settings of the VM in question. I found that I had to retrieve the settings first because I needed the “changeVersion” value to be able to set the recovery settings.
Set Recovery Settings
So finally, I have all that I need to be able to set the recovery settings and change the priority of the VM. There where some mandatory values needed in “settings” in parameter, but as these where default values , I was able to set them as variables in the workflow.
So there you have it. A quick overview of how I achieved this using SOAP API. An up skilling for me but was a nice challenge. I will now tidy the vRO workflow up and get it testing in our acceptance environment. Reach out if you have done something similar as would be great to hear alternative ways to achieve this.
Hi Brian,
Thanks for the article and its really interesting.
I have a similar use case and currently exploring different options like powerCLI as well.
I tried replicating your workflows and have few questions. If you could help that would be great and appreciated.
– How are you authenticating subsequent workflows like “ListProtectionGroups” after “srmLoginLocale”?
– In my case any subsequent workflow fails on authentication.
If you could talk a bit more about that would be very helpful.
Cheers,
Mehul
Hi Mehul,
Thanks for your interest in the post.
I am pulling the SRM credentials from a password repo and using them as input parameters for my WF. For example you can see there are lines:
request.setInParameter(“username”,ProtectedSiteSOAPUsername);
request.setInParameter(“password”,ProtectedSiteSOAPPassword);
These parameters are injecting the credentials into each different SOAP request i am making, eg getting protection groups, getting recovery plans or setting recovery plan. At the end of each request i am logging out because i hit some issues with max concurrent connections allowed to SRM and if the WF failed at some point during the request it would keep the connection live.
You will need to somehow supply these or SOAP will not allow authentication.
I hope this helps.
Thanks,
Brian