VCSA API - Exploring the Update Endpoints

In this post I will take a closer look at the available Update endpoints for the vCenter Server Appliance in version 6.7.

When revisiting a previous post on VCSA monitoring I wanted to add in information about the available updates.

Update information in the management interface (VAMI)

This info is accessible in the Management interface (VAMI) where we have the Updates section which lists the available updates.

VCSA available updates

VAMI update page

Update information through the REST API

Now let’s see how we can retrieve this information through the REST API. To get started with the VCSA appliance check out this post where I go into more detail about the APIs.

The corresponding API endpoint for available updates are under the /rest/appliance/update section.

If I run this in the API explorer I get the following response

API result

API result


Wait, what? It says UP_TO_DATE??

It’s somewhat of a surprise that the endpoint says UP_TO_DATE while the VAMI shows 5 available updates.

In short that endpoint checks available updates against the current version. In my example that would be 6.7.40000 and with that in mind it is correct that there’s no available updates.

If I specify the version I want to check against in the /rest/appliance/update/pending endpoint I get a different response and I see that there are updates pending.

API specifying version

API Result with specific version

You can also add the query parameter ?source_type=LAST_CHECK to the pending endpoint instead of specifying a version which is what I’m doing in my scripts. This is unfortunately not documented in the API explorer and it’s not possible to do directly there. If we run the /rest/appliance/update/pending we get an error

Update pending error

If we add in the source_type query parameter with one of the valid values (LOCAL, LOCAL_AND_ONLINE, LAST_CHECK) the error is gone and we get some results. The following output is from Postman and here we are using the LOCAL_AND_ONLINE parameter which will run the check against both the local and online update repository.

Postman output with update information


We also have the /rest/appliance/update/policy endpoint which gives information about the update policy which also includes if and when updates are checked automatically

Update policy


Performing an update

So until now we’ve not performed any action against the VCSA (well, we have actually run a check against update repos so technically that could maybe count as performing an action), we’ve only pulled information out. The API let’s us also run updates so let’s quickly check that out

We have several steps we can take in the update process including running a precheck, staging the install and performing the actual installation. First we will run a precheck. We use the API endpoint /rest/appliance/update/pending and include the version and the action=precheck as query parameters.

Run precheck through API


Ok, so let’s stage the install, still using the /rest/appliance/update/pending endpoint, but now with the version and action=stage as the query parameters.

Stage install through API

Note that this endpoint doesn’t provide any response back besides the status code of 200 which indicates a success.

With the staging success we can verify this with the /rest/appliance/update/staged endpoint

Staged installs through API

And we can verify the same in the VAMI

Staged installs through VAMI

Now, let’s perform the actual install! The endpoint takes a query parameter with the version, and the action which will be install, and for this we also need to include a body to the request where we need to provide the SSO password.

Request body for install endpoint


Starting install through API

This endpoint also responds only with the status code

Verify the install in the VAMI

VAMI update finished

Summary

This post has shown how we can work with VCSA updates through the REST API. Most of this came in 6.7 so if you are on an older version you might have to upgrade to that first.

I’ve used the built in API explorer for most of the API calls, but this is only for demonstrating the endpoints. In a real-world situation you would do this through some REST client, script or a CLI tool. If you want to have an example of a Powershell module built around this check out this post from David Stamen.

Happy RESTing!

This page was modified on April 4, 2020: Adding update post and a lot of pics