To track CPU Support in VCF releases, we have a dedicated KB article that shows which CPU are either Deprecated or Discontinued. See CPU Support Deprecation and Discontinuation In VCF Releases – KB 318697

A use case was brought to my attention by a colleague, the concept was to have a custom dashboard capability in VCF Operations (formerly Aria Operations) that could display status of CPU support, based on the below KB article.

And here we are now, with me writing this post to showcase one way of implementing such capability.

The Challenge

VCF Operations is a powerful platform for advanced monitoring and reporting on your VCF infrastructure, but out of the box it has no awareness of CPU lifecycle status.
The KB article is a static document, it tells you which CPUs are affected, but it doesn’t tell you which of your hosts are running them, or how urgent the situation is across your entire estate.

The goal was to bridge this gap: take the data from KB 318697 and represent it directly on a VCF Operations dashboard, per host, with colour-coded heatmap.

“Architecture” of my proposed solution.

The solution has three components that do work together:

1. A versioned JSON database (cpu-eol-db.json)
2. A PowerShell script, that leverages native PowerCLI cmdlets (Set-VCFHostCPU.ps1)
3. A VCF Operations Dashboard

1) The JSON Database

Rather than hardcoding CPU models into a script, the EoS/EoL data is externalised into a structured JSON file. This makes it trivial to update as Broadcom revises the KB article, without touching any code. The file includes a keyed VCF version, meaning for any future release we can customise future CPU familes EoS/EoL status.

JSON file https://github.com/giulianoberteo/eol-cpu-vcf-ops/blob/main/cpu-eol-db.json

Couple of important observations for the JSON key/value pairs:

• the PS script uses regEx (regular expression) to match the CPU family type. This means that if you your CPU type is E2680 v4, just leaving a single object like following
  { "series": "E5-2600 v4", "codename": "Broadwell-EP" }
  will not work. You need to be specific about it, which is why I added the object
  { "series": "E5-2600 v4", "codename": "Broadwell-EP" }
• I have removed all references of Intel Xeon or Xeon or Series or AMD because it’s not necessary for the purpose of CPU type matching and the order on which that is displayed on vCenter does interfere with detecting the correct CPU model.

2) The PowerShell script

The script connects to vCenter Server, reads the CPU model string from each ESXi host’s hardware summary, matches it against the JSON database, and writes the result back to vCenter as Custom Attributes. It handles the full lifecycle: creating the attribute keys on first run, overwriting values on subsequent runs, and providing a clear colour-coded console output as it progresses.

PS file https://github.com/giulianoberteo/eol-cpu-vcf-ops/blob/main/Set-VCFHostCPU.ps1

Six custom attributes are written per host, as summarised in this table:

Custom Property	Example Values
CPU_Code	0, 1, 2
CPU_Status	Supported, Deprecated, Discontinued
CPU_Codename	Broadwell-EP
CPU_Series	E5-2600 v4
CPU_VCF_Version	9.x
CPU_KB_Reference	https://knowledge.broadcom.com/external/article/318697

The prerequisites are minimal: just the VMware PowerCLI module and the two files in the same folder.

First provide the vCenter Server credentials to a PS variable as following

$vc_creds = Get-Credentials

Invoke the script

./Set-VCFHostCPU.ps1 -vCenterHost vcf-mgmt-vc.vlabs.local -Credential $vc_creds -SkipCertificateCheck

Example of a successful first time run against a vCenter

Once the custom attributes are written in vCenter, VCF Operations collects them automatically and makes them available as properties on HostSystem objects.
These properties can then be used in Views, Custom Groups, and Dashboards; giving you a live, queryable view of CPU lifecycle status across your entire fleet.

The following is a screenshot from vCenter Server

Why vCenter Custom Attributes Instead of VCF Operations Custom Properties?

VCF Operations does have its own custom property mechanism. The initial versions of my solution used that approach. However, there is a significant operational problem: VCF Operations custom properties cannot be deleted. Once a key is written to a resource object, it is permanent. This makes iteration painful — if you rename a property, the old key remains forever alongside the new one, cluttering every host object indefinitely (unless you delete the host object and re-discover it!)

vCenter Custom Attributes, by contrast, are fully manageable. They can be created, edited, and deleted at any time from the vCenter UI under Tags & Custom Attributes.

VCF Operations collects these attributes automatically and surfaces them under Summary | Custom Tag on each host object, as key/value pairs — making them fully usable in dashboard widgets and alert definitions.

The following is a screenshot from VCF Operations 9.0

Properties > Summary > Custom Tag view from VCF Operations

 

3) VCF Operations Dashboard

Once the attributes are in place and VCF Operations has collected them you can build a dashboard that shows a heat map of hosts by EoL status as well as a list view.

The steps I used to build a custom dashboard are:

3.1) Create List View

You can pick and choose how many properties and metric you want but for this use case a simple list should contain the following metrics:

Metric Name	Metric Label
Summary|Custom Tag:CPU_Status|Value	CPU Support
CPU|CPU Model	CPU Model
Summary|Parent vCenter	vCenter
Summary|Parent Cluster	Cluster
Summary|Custom Tag:CPU_Codename|Value	CPU Codename

Select Host System as Subject type for the View. Reference screenshot

3.2) Create Super Metric

We need a super metric in order to return the CPU_Code value into a Heatmap, applied to Host System as object type.
I created a super metric called cpuSupportStatus_v2 which contains the following formula, used to return 1 or 2.

count(${this, metric=summary|customTag:CPU_Code|customTagValue, where="summary|customTag:CPU_Code|customTagValue contains 2"}) * 2 + count(${this, metric=summary|customTag:CPU_Code|customTagValue, where="summary|customTag:CPU_Code|customTagValue contains 1"})

Screenshot as reference

3.2) Create Dashboard

Now we can it all together and build the dashboard.

First, drag a List View component and map the the Output Data to the list previously created.

Then drag a Heatmap component and configure the Output Data as following:

The Final Result

The finished custom dashboard will look like this:

Future Updates

When Broadcom updates KB 318697, the only maintenance required is updating cpu-eol-db.json and re-running the script. No dashboard changes, no attribute key changes — the values on each host are simply overwritten with the latest data.

I hope you found this useful and thanks for reading !