Thanks to Thomas Kopton for his inputs!
VCF Operations provides several management packs to enhance its capabilities for managing external systems. If for a component (e.g. a storage device) no existing management pack is available, customers can use the management pack builder to create a new pack on their own. The beauty of this is that no programming skills are required, provided the external component has a REST API interface available. Users are guided by a wizard that retrieves all relevant parameters from the API and finally builds a management pack .pak file.
While this is very helpful to attach new components to VCF Operations, customers might want to extend an existing management pack/adapter with more metrics. The management builder supports both paths.
In this blog I would like to show how the vCenter Adapter can be extended by custom properties using the management pack builder. As an example, I will demonstrate how to add the “Default Storage Policy” name of a vSAN datastore as a property to the datastore object in VCF Operations. The process is however applicable to any other value that the vCenter API supports.
Once the solution has been implemented you will see the new properties side-by-side to the existing properties of a vSAN datastore object.
Management Pack Builder
The Management Pack Builder is a separate appliance that will be installed in your environment and is accessible through a web page. You can find the download files on the Broadcom marketplace.
After the download you need to follow the installation instructions from the documentation.
As a pre-requisite you a connection to a vCenter (to retrieve the API data from) is required as well as a running VCF Operations installation where object details are extracted and where the management pack can be tested.
In the initial steps of the management pack builder setup, you will establish the connection to the VCF Operations instance using your credentials.
Creating a Management Pack
Creating a Design
The first step will be creation of a new design. It simply requires a name of the Management Pack which will show up in the VCF Operations integration details. Also, a more in-depth “solution description” is helpful as well as a version number.
After each build the management pack builder automatically increases the version number.
For those of you who don’t want to do the heavy lifting themselves there is an export of the management pack design available for download.
Defining a Source
The source represents the system where the desired metric is retrieved from through a REST API. In our case this is the vCenter server which provides us with the “Default Storage Policy” data. For vCenter the user-based authentication can be used to get the api token for further requests. Find below the procedure to integrate a vCenter server as source. Make sure the system is available on the network as the API call is verified.
Specify the vCenter URL and base API path. If self-signed certificates are used it will be helpful to disable SSL verification.
Add the username and password for the test API call. Later this data will be provided for the actual environment when configuring the management pack adapter in VCF Operations. Make sure you enable the “Will session authentication be used?” as this is mandatory to leverage the API key gathered for subsequent API calls.
Next, the api request required to get a session and token must be specified.
Authorization data is automatically added.
A test request is sent to verify if the session token will be properly retrieved.
In the Session Fields section you must check the hook for the response body and copy the variable that represents the api token using the copy button on the right hand side.
Now you will create a new header “vmware-api-session-id” and insert the copied variable reference to the api token as value. This header is used for subsequent API calls to make sure the right authentication is used.
No changes on this page needed.
Here you must specify an URL that is used to verify that the API works. I used the same API call I will leverage in the following sections to retrieve the datastore list, but in general it’s not relevant which API call is used here.
No additional data required here.
Finally, you start a test request to the api call provided before. If this is successful you can save the source configuration.
Getting vCenter API details
The most important part for creating a management pack is making sure having the right API calls available for the source where the data is taken from. For vCenter you can leverage the integrated “developer center” to find the corresponding API call or use the documentation available. There might be multiple API calls need to get the correct information out of the system.
In our example we will be using 3 api calls:
- List datastores
https://developer.broadcom.com/xapis/vsphere-automation-api/v8.0.0/vcenter/api/vcenter/datastore/get/ - Get Datastore default policy
https://developer.broadcom.com/xapis/vsphere-automation-api/v8.0.0/vcenter/api/vcenter/datastore/datastore/default-policy/get/ - List Storage Policies
https://developer.broadcom.com/xapis/vsphere-automation-api/v8.0.0/vcenter/api/vcenter/storage/policies/get/
API call 3 is chained to 2 and API call 2 is chained to 1.
To get the default storage policy name you must first get the datastoreID from the list of datastores. Then you etrieve the default storage policy ID using the datastoreID. Finally, you get the storage policy name from the list of storage policies by the storage policy ID.
This is how the API requests in the following sections are built up.
Create request for “list datastores”
Add a new api request
Noch chaining possible/needed as it’s the first request.
Add API Path and friendly request name.
No changes needed here
Testing the request should retrieve a list of available datastores with their details.
No changes needed here – save the request
Create request for “Get Datastore default policy”
For the next request you need to enable chaining as it uses the result from the previous request.
Add a parameter that references the “datastore” attribute.
Copy the variable of the datastore parameter.
Use this API Path (requestParameter is pasted from the clipboard):
vcenter/datastore/${requestParameters.datastore}/default-policy
Specify a friendly request name
No changes needed here
Test the request and save it.
Create request for “List Storage Policies”
Again, this request requires chaining as it takes the default storage policy ID from the previous call to retrieve the storage policy name
Add a parameter (only 1 option available)
Copy the variable for the Datastore Default Policy ID by clicking on the copy icon.
Add the proper API Path and Request Name
Add a new header to the request with the name “policies” and the value being the variable copied from the previous process.
Testing the request should show all available storage policies.
No changes needed here – the request can be saved
Create an object type
Now as we have all required API requests in place, it’s time to specify which VCF Operations object should be created or extended. As we want to extend the vCenter datastore object, we select “Extend Object”.
The available objects are retrieved by the vCenter connection where you must filter for datastore and select the datastore object.
As we are looking for the default storage policy name, we select the appropriate attribute in the next screen.
The management pack builder automatically retrieves the possible properties to be added. We will tailor the name of them as this will be how they appear in VCF Operations.
Here we will specify which existing property of the object is mapped to the API parameter needed to do the call. This is the point where depending on the datastore selected in VCF Operations the proper API call is made to the vCenter to get the corresponding data. As examples are show for the data retrieved (e.g. datastore-18) it will be simple to map the correct parameters.
Building the management pack
Important note:
We highly recommend using a test instance of VCF Operations when the resulting management pack is imported. Metrics and properties once added by the management pack hardly can be removed anymore. So, if you later decide to e.g. change the name of your management pack or single metrics you will get stale objects.
For building the management pack you go to the “build” section first. Next you will perform a data collection from the running VCF Operations instance to finally test if all data is received properly.
When clicking the build tab, the management pack is built automatically. After a few seconds it is available for download or can directly be imported into the connected VCF Operations installation.
Testing the management pack
After the management pack has been installed in VCF Operations, it shows up in the repository like any other pack.
You need to add a cloud account to configure it. In the configuration screen FQDN of your vCenter as well as the username and password used for API access are specified. After validation of the connection, the cloud account can be saved.
Once done the data collection should start after a couple of minutes and the status should show OK.
Now the properties will show up with the correct values in any vSAN datastore object.
In case you face any issues with the pack, there is a log file for each adapter in the log section of VCF operations. Warning and Info messages mostly are not critical, so first you should look for error or debug entries.
Have fun!
- Capacity Management for vSAN Storage Policies - 20. December 2024
- Extend vCenter metrics with Management Pack Builder - 20. December 2024
- VCF Automation – VM with post script execution - 18. December 2024