VKS Update fails with “supervisor content is being processed”
While preparing an update of our Supervisor cluster (VKS01) from v1.32.9 to v1.33.13 on vSphere 9.1, the update wizard looked perfectly healthy at first: the pre-checks in step 1 turned green. Then, in step 2 (“Review”), the wizard refused to continue with this error:
A general system error occurred. Error message: supervisor content is being processed.
The message is generic and does not tell you what content is being processed, or why it never finishes. A search in the Broadcom Knowledge Base did not return an article for this exact wizard error, but the same string shows up in several related articles – always in connection with the Supervisor Content Library.
Finding the real error
The wizard error is only a symptom. The actual cause is displayed one level up: in the vSphere Client under Supervisor Management > Updates, a red banner appears at the top of the page:
Error processing Content Library 2b654261-0890-4ceb-b767-f1a71ba7403e, Error: malformed Supervisor OVF template name ‘ob-24773265-ubuntu-2204-amd64-v1.28.15—vmware.3-fips-vkr.3’. The template name must be in the format ‘supervisor-<supervisor version>’. Example: supervisor-9.1.0.0-25004320.
This is the key. The Content Library that is assigned for Supervisor content distribution contains an item that does not belong there:
- Expected: items named supervisor-<version> (the Supervisor update images).
- Found: a vSphere Kubernetes release (VKr) node image for guest clusters – Ubuntu 22.04, Kubernetes v1.28.15 – named ob-24773265-ubuntu-2204-…-vkr.3.
The Supervisor tries to parse every item in the library as a Supervisor template. Because this item does not match the naming format, the library is never marked as processed, the catalog is not “ready”, and every operation that needs the Supervisor content – including the update – fails with “supervisor content is being processed”.
Why this happens
VKr images and Supervisor images are two different content types and should live in different libraries. A typical cause is that a single (often local or subscribed) library was assigned for both purposes, or that a library with VKr images was assigned to the Supervisor by mistake. The same pattern is described in several Broadcom articles:
- KB 412096 – the Supervisor logs “supervisor content is being processed” / “catalog is not ready”, Content Distribution shows “Error processing Content Library … malformed Supervisor OVF template name”, and the host configuration gets stuck.
- KB 416011 – an unknown library was incorrectly associated with the WCP service, so the Supervisor content library was never initialized.
- KB 442757 and KB 440378 – a non-VKS item or library in the content library configuration breaks the VKS/Supervisor service compatibility pre-checks.
How to confirm it on VCSA
If you want proof before changing anything, check the WCP service log on the vCenter Server Appliance:
grep -E "content is being processed|catalog is not ready" /var/log/vmware/wcp/wcpsvc.log
Hits such as the following confirm the problem:
error wcp [content/catalog.go] catalog is not ready
error wcp [kubelifecycle/pman_client.go] supervisor content is being processed
You can also run the VCF Diagnostic Tool for VKS (KB 402184) for a broader health check of the Supervisor:
python vdt.py -p vks
The Fix
Before you start: take a snapshot or backup of the vCenter Server. Also make sure that no guest cluster still depends on the VKr image you are about to touch.
Option A – Unassign the library from the Supervisor (KB 412096)
- Connect to the VCSA via SSH and start the interactive CLI: dcli
- List the libraries associated with the Supervisor and note the ID of the affected library:
com vmware vcenter namespacemanagement lifecycle content libraries list
- Unassign the library (use the ID from the error banner, here 2b654261-0890-4ceb-b767-f1a71ba7403e):
com vmware vcenter namespacemanagement lifecycle content libraries unassign --library 2b654261-0890-4ceb-b767-f1a71ba7403e
- Open Supervisor Management > Content Distribution and verify that the error is gone, then restart the Supervisor update wizard.
Option B – Remove the offending item from the library
If the library is still needed, delete the VKr item (ob-…-v1.28.15…) from it instead, or move it to a dedicated library that is used only for Kubernetes releases. KB 440378 describes the same approach for a non-VKS image in a local library. Check first that no guest cluster still runs v1.28.15.
Option C – Last resort: database cleanup
A community write-up (lab2prod) removes the broken row from the supervisor_content_source_configs table in the VCDB and restarts the WCP service with vmon-cli –restart wcp. This is a direct database change, not an official procedure – only do it together with Broadcom Support and with a verified backup.
After the Fix: Keep the libraries separate
- Use one library for Supervisor content distribution – it should contain only supervisor-<version> items.
- Use a separate (usually subscribed) library for VKr node images and assign it to the Supervisor/namespaces for Kubernetes releases.
- Remember to wait for running Content Library synchronizations to finish before starting an update (KB 442757, root cause 2).
- Also check the supported path: Supervisor v1.33 requires vCenter 8.0 U3j or later (KB 451590) and a compatible VKS service version (KB 444485).
After that you should be able to update the Supervisor Cluster.
That’s it if you have any questions please use the comment section below or contact Broadcom Support. 🙂