Quick Start With Lifecycle Manager REST APIs

Just a few years ago coming across an infrastructure product (software or hardware) that supports REST APIs was a rare thing. Today it’s the opposite. Buying, say, a storage array from a major vendor, that doesn’t support some sort of an API can be seen as a potential drawback. It’s now gotten to a point where certain operations can only be done via API and are not available in the GUI. So basic programming skills become more and more important.

I have come across such situation with vRealize Suite Lifecycle Manager (vRSLCM or just LCM) product from VMware. If you have a request that got stuck, the only way to cancel it (at least at the time of writing) is to use LCM’s REST APIs. It can’t be done from the GUI.

While I was tackling this issue, I noticed that there aren’t many articles on how to make REST calls to LCM on the Internet, so I though I’d use this opportunity to show how to do it.

Authentication

First challenge you have to deal with is authentication. LCM doesn’t support basic authentication, like other products, for instance NSX. You need a token.

This is how you can get a token in Postman:

• Submit a POST call
• Use the following URL – https://lcm-hostname/lcm/api/v1/login
• Enter the following body:

{
	"username":"admin@localhost",
	"password":"vmware"
}

This is what it will look like in Postman:

When you click send you should get a token in response:

Making REST Calls

Now you need to specify the token as one of the headers, with “x-xenon-auth-token” as key and the token itself as value:

From here, you are ready to make actual REST API calls. Coming back to our example, we can go to LCM GUI and copy the ID of the stuck request from the browser window:

And then make a DELETE call with empty body to cancel the request:

As a result, traces of the request will be completely deleted from LCM.

Note: The only catch here, that you have to remove “v1” version of the API from the URL. Or it will not work.

Swagger UI

LCM supports Swagger, which lets you run REST API calls straight from the browser. So if you want to feel yourself a hacker, open the https://lcm-hostname/api URL and you can get the token and make requests by simply using the “Try It Out” button, specifying required parameters and hitting “Execute”.

Advertisement

Creating vRealize Operations Manager Alerts Using REST API

Whenever I’m faced with a repetitive configuration task, I search for ways to automate it. There’s nothing more boring than sitting and clicking through the GUI for hours performing the same thing over and over again.

These days most of the products I work with support REST API interface, so scripting has become my solution of choice. But scripting requires you to know a scripting language, such as PowerShell, certain SDKs and APIs, like PowerCLI and REST and more importantly – time to write the script and test it. If you’re going to use this script regularly, in the long-term it’s worth the effort . But what if it’s a one-off task? You may well end up spending more time writing a script, than it takes to perform the task manually. In this case there are more practical ways to improve your efficiency. One of such ways is to use developer tools like Postman.

The idea is that you can write a REST request that applies a certain configuration setting and use it as a template to make multiple calls by slightly tweaking the parameters. You would have to change the parameters manually for each request, which is not as elegant as providing an array of variables to a script, but still much quicker than clicking through the GUI.

Recently I worked on a VMware Validated Design (VVD) deployment for a customer, which required configuring dozens of vRealize Operations Manager alerts as part of the build. So I will use it as an example to demonstrate how you can save yourself hours by doing it in Postman, instead of GUI.

Collect Alert Properties

To create an alert in vROps you will need to specify certain alert properties in the REST API call body. You will need at least:

• “pluginId” – ID of the outbound plugin, which is usually the Standard Email Plugin
• “emailaddr” – recipient email address
• “values” property under the alertDefinitionIdFilters XML element – this is the alert definition ID
• “resourceKind” – resource that the alert is applicable for, such as VirtualMachine, Datastore, etc.
• “adapterKind” – this is the adapter that the alert comes from, such VMWARE, NSX, etc.

To determine the pluginId you will need to configure an outbound plugin in vROps and then make the following GET call to get the ID:

• https://vrops-hostname/suite-api/api/alertplugins

To find values for alert definition, resource kind and adapter kind properties, make the following get call and search for the alert name in the results:

• https://vrops-hostname/suite-api/api/alertdefinitions

Create Alert in vROps

To create an alert in vROps, you will need to make a POST call to the following URI in XML format:

• Use the following request URL: https://vrops-hostname/suite-api/api/notifications/rules
• Click on Headers tab and specify the following key “Content-Type” and value “application/xml”
• Click on Body tab and choose raw, in the drop-down choose “XML (application/xml)”
• Copy the following XML request to the body and use it as a template

<ops:notification-rule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ops="http://webservice.vmware.com/vRealizeOpsMgr/1.0/">
<ops:name>
No data received for Windows platform
</ops:name>
<ops:pluginId>c5f60db9-eb5b-47c1-8545-8ba573c7d289</ops:pluginId>
<ops:alertControlStates/>
<ops:alertStatuses/>
<ops:criticalities/>
<ops:resourceKindFilter>
<ops:resourceKind>Windows</ops:resourceKind>
<ops:adapterKind>EP Ops Adapter</ops:adapterKind>
</ops:resourceKindFilter>
<ops:alertDefinitionIdFilters>
<ops:values>AlertDefinition-EP Ops
Adapter-Alert-system-availability-Windows</ops:values>
</ops:alertDefinitionIdFilters>
<ops:properties name="emailaddr">vrops@corp.local</ops:properties>
</ops:notification-rule>

As described before, make sure to replace the following properties with your own values: “pluginId”, “values” property under the alertDefinitionIdFilters XML element, resourceKind, adapterKind and emailaddr.

As a result of the REST API call you will get an alert created in vROps:

For every other alert you can keep the plugin ID and email address the same and update only the alert definition, resouce kind and adapter kind.

Conclusion

By using the same REST call and changing properties for each alert accordingly, I was able to finish the job much quicker and avoided hours of pain of clicking through the GUI. As long as you have a REST API endpoint to work with, the same approach can be applied to any repetitive task.

If you’d like to learn more, make sure to check out VMware {code} project here for more information about VMware product APIs and SDKs.