Disclaimer: The solution described in this post, including the PowerCLI script, JSON database, and dashboard configuration, is not officially supported by Broadcom or VMware. It is provided as-is, for informational and educational purposes only. Always test in a non-production environment before deploying to production. The author accepts no responsibility for any issues arising from the use of this solution.
The Challenge
Managing infrastructure at scale means keeping on top of more than just uptime – it means staying ahead of hardware lifecycle events before they become compliance or supportability issues.
VMware Cloud Foundation has a clear and well-maintained position on CPU support: a dedicated KB article tracks which processor families are Deprecated or Discontinued across VCF releases, giving administrators the information they need to plan hardware refreshes accordingly. See CPU Support Deprecation and Discontinuation In VCF Releases – KB 318697
The challenge, however, is that a KB article is a static reference. It tells you which CPUs are affected but not which of your hosts are running them, how many are at risk, or how urgently you need to act. In a large environment with dozens (or hundreds) of ESXi hosts spread across multiple clusters, manually cross-referencing hardware inventory against a KB article simply doesn’t scale.
A colleague brought this exact problem to my attention, with a compelling idea: what if VCF Operations could surface that CPU lifecycle status directly on a dashboard – per host, colour-coded by severity, and always reflecting the latest KB data? No spreadsheets, no manual checks, no chasing teams for inventory exports.
That conversation is what led to this post. What follows is one way to implement exactly that capability, combining a versioned JSON database, a PowerCLI script, and native vCenter Custom Attributes to bring CPU lifecycle awareness directly into your VCF Operations dashboards.
“Architecture” of my proposed solution.
The solution has three components that do work together:
- A versioned JSON database (
cpu-eol-db.json) - A PowerShell script, that leverages native PowerCLI cmdlets (
Set-VCFHostCPU.ps1) - 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
Few 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 Series", "codename": "Broadwell-EP" }
will not work. You have to be more specific about it (in my case E5-2680 v4) which is why I added the following object:{ "series": "E5-2680 v4", "codename": "Broadwell-EP" }
You’ll also notice that, compared to the family type displayed in the KB article, I 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
PLEASE NOTE: In my nested VCF lab, I connect to vCenter Server using administrator@vsphere.local; perfectly acceptable for lab, dev, and test environments.
In production, however, you will almost certainly want to follow the principle of least privilege. A solid approach for any production environment is to have a dedicated service account (either vsphere.local on your corporate directory) scoped with only the permissions required to create, edit, and delete Custom Attributes on Host objects.
In my system I created inventory-tagging-svc@vsphere.local 
Assign such account to a custom role whic I named Custom-Attributes-Tagging where the only privileges are Manage custom attributes and Set Custom Attributes
This way whenever a change is executed from the script, the logs will be very clear as to what entity performed the change and when.
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 we 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
We can pick and choose how many properties and metric we 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
VCF Operations Heatmaps are a powerful way to visualise the health of your infrastructure at a glance but they have one important constraint: they can only plot numeric metric values. Custom Attributes, while queryable and filterable elsewhere in VCF Operations, are string-based properties and cannot be used directly as a Heatmap data source.
This is where a Super Metric comes in. A Super Metric is a user-defined formula that VCF Operations evaluates on a schedule, producing a numeric output that is stored and treated like any other metric; and therefore fully compatible with Heatmaps, alerts, and trend analysis.
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. For my Table Input Data I selected my VCF management workload domain named vcf-sddc-s1
and as Output Data, the table view I created earlier, named CPU EoS Inventory – v2
The second part of the custom dashboard is the Heatmap. Drag a new Heatmap component into the canvaas and configure the Output Data as following:
Once done with editing, your canvas should similar to this:
The Dashboard
The finished custom dashboard should look like this:
Future Updates
As it stands today, keeping the solution current is a deliberately simple process. When Broadcom updates KB 318697, the only action required is updating cpu-eol-db.json to reflect the latest CPU lifecycle changes and re-running the script. No dashboard reconfiguration, no attribute key changes; every host in your estate is simply re-evaluated and updated on the next run.
That said, a good point was raised during peer review: wouldn’t it be even better if the JSON file updated itself automatically whenever the KB article changed? No manual steps at all, fully self-maintaining. I completely agree, and it’s a feature I’d love to add. The tricky part is the KB article itself. The tables and formatting are inconsistent enough that automatically parsing the page reliably is harder than it sounds. Getting it mostly right isn’t good enough here, if the PS script silently pulls incorrect data, you’d end up with wrong lifecycle statuses on your hosts without realising it.
For that reason, automated KB synchronisation was left out of scope for this first version. It’s something I’d like to revisit and if I crack it, I’ll write a follow-up post covering that piece. Stay tuned!
I hope you found this useful and thanks for reading and I welcome any feedback.