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.

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

\

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.

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

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.

\

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

\

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.

\

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.

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

And we can verify the same in the 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.

\

This endpoint also responds only with the status code

Verify the install in the VAMI

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!