In Part I, I showed how to deploy the Lifecycle Manager appliance.

For my first product deployment, I decided on a quick win with Log Insight.

When you log in to vRealize Suite Lifecycle Manager the first time, it takes you through a tour of the UI.

First I generated a certificate

Then I clicked to create a new environment

If you have a My VMware account with acccess to vRealize Suite, you can poined LCM directly to My VMware as a download source, you won’t have to manually download bits.

Changing passwords forced a logoff and login.

Enter your My VMware credentials here to allow for direct download

Click on the items you want to download

Add a new datacenter for LCM to manage

Now adding a new vCenter to the datacenter

Starting the wizard to deploy Log Insight

I’m only installing Log Insight at this time, so check the box.

Now you get a short Log Insight wizard.

I’m only doing a standalone LI host but note you could do a load balanced config as well as add worker nodes.

The job after it’s submitted.

The deployment failed because it wants to put 16 vCPU on my LI VM, but my little lab only has 4 cores per host. The vCenter error said “No host is compatible with the virtual machine.” All I had to do was edit the deployed VM, change it to two cores (I also decreased the RAM), power it on and the LCM deployment continued without issue.

I now have a running Log Insight instance, I connected it to vCenter and I’m done!

vRealize Suite Lifecycle Manager is designed to let you manage deployment and upgrades of vRealize Suite. In Part I of this series, I will show you the installation process in my lab.

Here is the OVF that I downloaded from My VMware

Deploy the OVF

Standard OVF deployment options here, setting the hostname and IP address information.

The console while the appliance configures itself

Main welcome screen – default credentials are admin@localhost / vmware

You will get asked to change the appliance password

All set, this is an easy, standard OVF deployment.

In Part II, I use vLCM to deploy Log Insight.

In Part I, I talked about why I wanted to learn API calls in vRA and how I got my lab environment working. In Part II, I will talk about how I learned how to make an API call.

I relied heavily on Grant Orchard’s getting started guides. I have linked to Part I, II, and III below, with my explanations of how I used his blog to achieve my goal.

Part I – Getting Started [grantorchard.com]

I couldn’t figure out how to browse through API calls because I wasn’t seeing what Grant was showing. It took me forever to realize that at the very bottom of the page, you  can click on Show/Hide – then the API calls appear and you can drill into each one for full details.

Part II – Building Your First API Call [grantorchard.com]

Grant wrote:
Before we start, perform the following steps.
1. Download Postman.
2. Import this Postman collection of the vRA 7.2 API.
3. Import this Postman environment variables file.
4. Open up the API docs at https://{{vra-fqdn}}/component-registry/services/docs

Postman? What’s Postman?  It’s a GUI tool to issue API calls.

What’s a Postman collection? It’s a group of API calls that you can easily click on in the GUI.

I can easily search a Collection for the API I want. In this case, I know I want to get the Bearer token (Grant explains this, it’s how the API requests are authenticated), so I search for ‘token’. I click on the “returns a token associated with the provided credentials” and it opens up the request complete with the proper URL. It saves me from having to manually piece together the API calls and paste them into Postman.

You’ve probably noticed {{vra-fqdn}} in the URL. It’s not just a placeholder. It’s an environment variable.

Grant provided a bunch of environment variables in his post – you can import the environment variables and change them to match your lab environment. You can reference these variables inside Postman.

Following Grants example, I opened the token API in Postman.  The ‘Tests’ section saves the Bearer token in a variable named “token”.

Part III – Requesting a Catalog Item [grantorchard.com]

Grant’s post said the API I needed was ‘entitledCatalogItemViews’. You can see that I’m using the {{vra-fqdn}} variable in the URL as well as passing the Bearer {{token}} value. One problem I ran into is that you must have a space between Bearer and {{token}}.

Hit Send and my results come back. I have only one blueprint, a Linked Clone blueprint with Photon Linux in it. You can see two links – one for the GET: Request Template, and the other for the POST: Submit Request. The Request Template will return an example set of JSON showing you how to make the POST call to start the Blueprint.

Now I open another Postman tab and paste in the Request Template URL. Add the proper header for Authorization, and hit Send.

This is just a subset of the JSON I got back. I left the tab open and launched a new tab.

In the new tab, I used the URL in the Submit Request response that I got above. I did the same Authorization header as used previously, and pasted the Template JSON from above into the Body field.

After pressing Send, I got this response in the Body. You can see a Request ID as well as a state of “Submitted”

There is also an API where you can check on the state of a request. You can see now that the state has changed from Submitted to In Progress. You can keep

You can see my request in progress inside vRA

You can also see activity in the vSphere Web Client.

You can continue checking on the provisioning status by clicking Send in Postman. You would do the same thing programmatically – periodically ping the API for this asynchronous request to determine when it has completed. We now see that the status code is Successful instead of In Progress

I now have a new Item in vRA.

Now that I know the correct APIs to use, and that they work as expected in my lab environment, I can get to work calling them from Powershell. Part III of the series will document this process.