I recently came across a really cool automation solution from Dale Coghlan who built a PowerShell module to interact with the VMware Configuration Maximum (Config Max) Tool.
So, I published a thing today.... VMware.CfgMax - A PowerShell module to interact with https://t.co/NBrbCO3hcf https://t.co/RRQkh7ma1q
— Dale Coghlan (@DaleCoghlan) December 1, 2020
Although the Config Max tool does not currently provide an API, there is still a way to interact with it programmatically. Behind the scenes, the application uses JSON for its payload which can then be retrieved programmatically using PowerShell or any other language for that matter to perform an HTTP GET. I also know the Config Max team quite well, as I had worked with them to incorporate the VMware Cloud on AWS configuration maximums which also required a few enhancements to the tool. If you have any feedback, feel free to drop a comment and I will be happy to share it with them and one of my first asks when I met the team, was to provide a public REST API 🙂
After sharing Dale's tweet, I saw a question about doing something similiar for the VMware's Product Lifecycle Matrix, which is a website that helps customers understand the support lifecycle of a given VMware product/solution. The product lifecycle site has also been recently revamped and although it also does not have a public API, using Chrome Developer Tools (super useful tool) to quickly inspect, it looks like you can also programmatically grab the payload which also happens to be using JSON 🙂
Disclaimer: The VMware Product Lifecycle Matrix does not provide a public API, this also means there are no guarantees or compatibility that the trick outlined below will continue to work going forward. This is why you want to have a public, documented and supported API.
Step 1 - Open a Chrome browser to https://lifecycle.vmware.com/ and then go More Tools->Developer Tools. If you are using another browser, there should be an equivalent option which you can Google online.
You will need to refresh the page, so the traffic is captured and then under Network section, type ?to into the search box. There maybe a few entries, just click on one of them and then look for the one with the x-auth-key header and copy the value, we will need this to make the request
Step 2 - Take the value of x-auth-key and then plug that it into either the PowerShell or cURL example below to programmatically retrieve the JSON payload which contains the data as shown in the web application.
A very cool potential tool/script that one could build is to now compare this against the products that you have running in your own environment and you can quickly determine when they will end-of-life without having to manually using the UI or export it into CSV 🙂
PowerShell
$lcm_matrix_url = "https://plm.esp.vmware.com/api/v1/release_stream/lifecycle_matrix/?to=12/01/2020" $x_auth_key = "FILL-ME-IN" $headers = @{ "accept"="application/json"; "x-auth-key"="${x_auth_key}"; } $requests = Invoke-WebRequest -Uri $lcm_matrix_url -Body $body -Method GET -Headers $headers ($requests | ConvertFrom-Json)
cURL
X_AUTH_KEY="FILL-ME-IN" LCM_MATRIX_URL="https://plm.esp.vmware.com/api/v1/release_stream/lifecycle_matrix/?to=12/01/2020" curl ${LCM_MATRIX_URL} -H 'accept: application/json' -H "x-auth-key:${X_AUTH_KEY}"
scott rosenberg says
this is awesome! unfortunately it seems that every API in VMware has different product IDs for the products making interoperability between the tools very complex. for example the API gateway which can show interoperability between products and also compatibility for drivers firware etc. has a completely different set of product IDs.
i really wish there was a standard for this which would make interoping between these tools much more feasible
Jason Gersekowski says
William,
It looks like the value of "x-auth-key" has now been hardcoded to "5507092c8c24473292a66d4b13ed0ef7" as of 8th October 2023. Is there any chance you can confirm if this will be a permanent change ?
Cheers,
Jason