With the release of Site Recovery Manager (SRM) 8.6 comes the introduction of REST API support. This has been a long sought after feature for SRM that we now finally have. Previously if you wanted to programmatically work with SRM you would have to use the SOAP API or vRealize Orchestrator. Both of which have a fairly steep learning curve. But now we have a more standardised way of working with SRM using REST.
Recently I decided to delve into these REST APIs to understand how they work and how might they be leveraged for my customers. I spent a little bit of time learning how to authenticate to SRM over the REST API, retrieve SRM configuration, and then configure SRM using these REST APIs.
I find many REST APIs have little nuances between them that you need to learn. But once you understand them everything else seems to fall into place fairly quickly. For me in this situation it was understanding the process of how to authenticate to SRM over REST.
Below I explain the process to get started working with the SRM REST APIs. The environment I used consisted of two sites with vCenter 7 U3 (U2 is the minimum version required to use the REST APIs) and SRM 8.6 deployed. SRM was configured with a single site pair connection between the vCenters and two Protection Groups.
I found the easiest way to get started was with the REST API Explorer in SRM. It’s accessible via the URL {https://protected_vc/api/rest/#/home}. I also leveraged SRM documentation over at https://developer.vmware.com/apis/srm-rest-api/latest/. The developer documentation is similar to what you’ll find out of REST API Explorer but I found it much easier to consume and understand with nicer examples.
Once you browse to the REST API Explorer the first thing you want to do is change the product from configure to srm. Configure refers to the VAMI APIs where srm is the actual SRM product APIs. Working with the SRM REST APIs can be broken down into a few steps. Below I outline these steps based off the developer documentation.
Step 1. Authenticating to SRM and retrieve a Session ID
We achieve this by making a POST request using the Authentication API.
Navigate to the authentication category and select POST (/session) and Execute
This will prompt you for your Protected vCenter credentials.
If successful, you will receive a 200 status response. In the response body returned you will have a session_id.
Step 2. Use the session ID for subsequent calls
Copy the session_id and paste it in the Session ID field at the top of the REST API Explorer page.
Step 3. Get Pairings
One of the most fundamental parameters you will need when using the REST API is the Pairing ID. Navigate down to the pairing API category and select the GET (/pairings) and Execute, which will Get a list of all existing pairings.
Returned in the response will be a pairing_id.
Step 4. Create a session to the remote Site Recovery Manager
If your vCenters are leveraging Enhanced Linked Mode this step may not be required. This step, though, is the official process that should be used, so we will use it here. While still under the pairing API category. Navigate to the POST (/pairings/{pairing_id}/remote-session) request. Take the pairing_id from the previous step and paste it into the pairing_id parameter and Execute.
You will be prompted to authenticate once again. This time you provide the remote vCenter credentials (not the local protected one).
If successfully a 204 status is returned with No Content.
Step 5. Begin making your calls
We have now completed the authentication and setup phase and we can now begin making our calls to the full set of SRM REST APIs.
There are a number of different types of calls we can make but by far the easiest and safest are just the GETs. GET calls won’t make any changes.
Let’s start with one of these easy ones for an example. Navigate down to the protection API category.
Select the first GET (/pairings/{pairing_id}/protection-management/groups) and paste in the pairing_id that we previously obtained and paste into the pairing_id parameter and Execute.
Returned in the response will be all Protection Groups that exist.
If you’ve reached this point successfully, it’s a good indication that everything is working and you can continue to make further calls. Always make note of the required parameters in a call. More complex calls required additional parameters be submitted along with the pairing_id.
Overall the new SRM REST APIs are a greatly welcomed addition. They are quite extensive in capabilities and should open the door to a larger community when it comes to automating SRM. I’m looking forward to delving further into these APIs into the New Year.
References
1 thought on “Getting Started With Site Recovery Manager (SRM) REST API”