Cosmin.us

Upgrading VCF 9.1 SDDC Manager to 9.1.1: A Step-by-Step Guide

Cosmin Trif — Tue, 15 Sep 2026 15:00:00 +0000

With VCF 9.1.1 available, I wanted to patch SDDC Manager in my lab. This is the follow-up to my VCF 9.0 SDDC Manager upgrade guide. In this post I will go over the upgrade from 9.1.0.0400.25570100 to 9.1.1.0.25713928 through VCF Operations.

VCF 9.1.1 is a maintenance release with an updated Bill of Materials. The VCF 9.1.1 release notes are the source of truth for supported paths and dependencies.

One naming detail before we start: these screenshots show SDDC Manager under Build -> Lifecycle -> VCF Instances. That is different from the SDDC Lifecycle management-service component under Build -> Lifecycle -> VCF Management. The procedure below is for SDDC Manager. This patches SDDC Manager only; it does not change the management-domain version or patch the other core components. Broadcom documents this standalone path in Upgrade SDDC Manager without upgrading VCF.

Before You Begin

For an existing 9.1.0.x environment, patch the Fleet Lifecycle management service to 9.1.1 first. Wait for that operation to complete before starting SDDC Manager. The release notes also require lifecycle operations to run sequentially; do not patch VCF Operations or another component in parallel.

Before opening the SDDC Manager page:

Confirm the source and target are supported in the VCF Upgrade Planning Tool and the Broadcom Interoperability Matrix. A standalone SDDC Manager patch is supported only when the target is compatible with the BOMs in the management and workload domains.
Download the SDDC Manager binary from Software Depot using the VCF Operations lifecycle procedure. Verify that VCF Operations can reach the configured depot. VCF 9.1 uses an activation code for depot access; resolve depot or proxy errors before downloading the bundle.
Verify a recent, successful SDDC Manager backup and that you have the restore details and credentials available. Schedule a maintenance window and make sure the people responsible for the VCF instance are available if a task needs attention.
Confirm that no other lifecycle task is running. The SDDC Manager bundle is about 3 GB, so allow time for the download and validation.

The versions from my lab are:

Component	Before	After
SDDC Manager	9.1.0.0400.25570100	9.1.1.0.25713928

The target build is also listed in the VCF 9.1.1 SDDC Manager release notes.

Open the SDDC Manager Upgrade Page

Log in to VCF Operations with an account that can run lifecycle operations. Go to Build -> Lifecycle -> VCF Instances, select the VCF instance, and open SDDC Manager Upgrades. Depending on the exact 9.1.x patch level, the page may present this as a planned component upgrade; follow the target version and precheck steps in the linked Broadcom procedure.

In my lab the instance is instance-a. The page shows the current build and the available 9.1.1.0.25713928 bundle. It is marked Latest Compatible, and the page displays a compatibility-warning link. Read those warnings and resolve anything that applies to your environment before continuing.

The page also shows the bundle ID and a DOWNLOAD (3 GB) button. If your page does not show the target, sync or fix the depot configuration first. Do not try to force a version that VCF Operations has not offered for the instance.

Download and Validate the Bundle

Click DOWNLOAD (3 GB) and wait for the download to finish. The bundle is staged and validated by VCF Operations; leave the task running until the status changes.

When the card reports that the download and validation are complete, confirm that the target still reads 9.1.1.0.25713928. Run the available prechecks and wait for them to pass before starting the upgrade.

Start the Upgrade

After the prechecks pass, click UPGRADE NOW. VCF Operations displays a confirmation that the SDDC Manager UI will be disconnected until the upgrade finishes. This is expected. Click START UPGRADE only after confirming that the maintenance window is open and no one needs the SDDC Manager UI during the operation.

Do not cancel the task or reboot the appliance manually. If the task reports a failure, open the task details, capture the error, and follow the corrective action in the release notes or Broadcom support guidance before retrying.

Monitor the Upgrade Workflow

The VCF Upgrade Status page shows the VMware Cloud Foundation Upgrade 9.1.1.0 bundle and the SDDC Manager resource in progress. The page also provides a release-notes link; use the canonical 9.1.1 release-notes page when checking dependencies.

Expand SDDC MANAGER UPGRADE to follow the individual stages. In my run the workflow moved through the VCF prerequisite, common appliance platform setup, service validation, package removal, Photon 4 RPM preparation, VCF service and platform updates, authentication, the SDDC Manager RPM update, reboot, certificate refresh, appliance-version update, deployment-drift check, post-validation, service validation, cleanup, and stopping the common appliance platform service.

Let the workflow finish all of its stages. The UI may be unavailable for part of the process, and the duration will vary with the environment. Wait for the overall task to report Completed before starting another VCF lifecycle operation.

Verify the New Version

Return to Build -> Lifecycle -> VCF Instances -> instance-a -> SDDC Manager Upgrades. The Current SDDC Manager version should now show 9.1.1.0.25713928.

Also review Lifecycle -> Tasks for a completed upgrade and check the VCF instance health, SDDC Manager services, certificates, and management-domain access. Before patching ESX from 9.1.0.x to 9.1.1.0, patch the VCF Operations instance and its connected license servers first. Also make sure no lifecycle operation is still running.

If you use an offline depot and its settings show legacy hostname, port, or username fields after the upgrade, review the SDDC Manager release-note workaround: reconnect the depot using the supported URL format or open Edit and save the corrected settings before downloading another bundle.

SDDC Manager in my lab is now on 9.1.1.0.25713928. We can continue with the remaining VCF 9.1.1 components by following the dependencies in the release notes. For the management-service side of the update, see my VCF 9.1.1 all-in-one upgrade runbook and the separate Fleet Lifecycle walkthrough.

Upgrading the VCF Migration Service Engine to 9.1.1 Step by Step

Cosmin Trif — Mon, 14 Sep 2026 12:30:00 +0000

With VCF 9.1.1 released on September 3, 2026, I continued upgrading the management components in my lab. In this post I will go over upgrading the Migration Service Engine from 9.1.0.0200 to 9.1.1.0 through VCF Operations. The task is labeled VCD_MIGRATOR in the workflow, so I use both names below.

This is the component upgrade that prepares the VCD migration service. It does not migrate workloads by itself. If you are preparing a VCD workload migration, also check the supported VCD baseline and the Environment Assessment Tool requirements in Broadcom KB 455238. Broadcom currently documents VCD 10.6.2 as the supported source for the VCF 9.1 migration path.

This is a follow-up to my VCF 9.1 management-services walkthrough, where the Migration Service Engine was still on the 9.1.0.0200 build.

The VCF 9.1.1 release notes are the authority for the release scope, dependencies, and known issues. The related VCF Automation build is listed in the VCF 9.1.1 Bill of Materials; the Migration Service Engine target below is the supported path offered by my VCF Operations UI.

Versions in This Upgrade

These are the versions shown in the VCF Operations UI during this run:

Component	Before	After
Migration Service Engine (VCD_MIGRATOR)	9.1.0.0200.25556825	9.1.1.0.25714559

The version numbers are the complete build strings from the upgrade path. Use the target offered by your own VCF Operations instance if it differs from the lab capture; do not force a target that is not presented as a supported path.

Before You Begin

For an existing 9.1.0.x environment, upgrade Fleet Lifecycle to 9.1.1 first. VCF Automation must also be on the required 9.1.1 level before you upgrade the Migration Service Engine. The VCF Automation 9.1.1 walkthrough covers that component.

Before starting the VCD Migrator operation:

Verify that the supported backup target is configured and reachable under Build -> Lifecycle -> VCF Management -> Backup & Restore. Follow the VCF backup and restore documentation for the backup method used by VCF Automation and keep the encryption passphrase available.
Take and verify a fresh VCF Automation backup when the Backup & Restore page offers that component. The Migration Service Engine is managed with VCF Automation; do not assume that a separate standalone backup option exists.
Confirm that the 9.1.1 binaries are present in the configured software depot. For an offline environment, prepare them with the VCF Download Tool and binary-management procedure. The VCF Download Tool identifies the migration backend as VCF_SERVICE_VCD_MIGRATION_BACKEND; KB 442857 covers that identifier.
Check VCF Automation and the VCF services runtime for healthy nodes, DNS, certificates, credentials, CPU, memory, and disk space. Resolve alerts before staging the package.
Make sure no other lifecycle operation is running. Run one management-component operation at a time and wait for it to finish before starting the next one.
If VCF Automation or the VCD Migrator was previously uninstalled and reinstalled, review KB 453702 before upgrading. Duplicate service-account Secrets can leave the 9.1.1 Migration Service unhealthy; take a backup and follow the supported remediation if the KB condition applies.
Plan a maintenance window and record the migration checks you will run afterward. This workflow can restart services, and the supplied captures show the upgrade entering progress rather than a completed task.

Selecting the Migration Service Engine

The target in my lab was already set to 9.1.1.*, and Fleet Lifecycle was already running 9.1.1.0.25713934. If your target still shows 9.1.0.*, click Select Version (shown as Change target version in some builds), choose 9.1.1.*, and set the new target. If 9.1.1 is missing, use Sync and wait for the lifecycle metadata task to finish.

Under Management Components, filter for migration and select the Migration service engine row for the VCF instance you want to upgrade. In my lab that instance was instance-a. Expand Check Required Binaries and resolve any missing binary before continuing.

The upgrade path should read 9.1.0.0200.25556825 -> 9.1.1.0.25714559.

Select the row. The action bar shows RUN PRECHECKS (1) and UPGRADE (1), and the row reports Ready for upgrade after the precheck has passed.

Run the Prechecks

Click RUN PRECHECKS (1) and open Precheck details. Review every result before starting the upgrade. The VCD Migrator precheck covers the staged component package, the virtual center connection, and the database upgrade checks.

The precheck workflow in my run completed with an overall Passed result. The four checks shown in the task were Component Package Staged Check, Component Package Staging Check, Virtual Center Precheck, and Database Upgrade Precheck.

Return to the upgrade list and confirm that the row still reports Ready for upgrade. If a check fails, correct the underlying issue and run the precheck again. Start the upgrade only after the row is ready.

Start the Upgrade

Click UPGRADE on the selected row. The status changes to Upgrade in progress and an Upgrade details link appears.

Open Upgrade details and follow the task from the Tasks tab. The workflow is named VCF_MIGRATOR Upgrade Workflow. In the supplied capture, the active subtask is Stage VCD_MIGRATOR plugin in VCF services runtime. Its messages show the binaries staging first and then Running Component Stage Prechecks.

The exact number and names of subtasks can vary with the installed VCF Automation build. Wait for the overall task to report Completed, including its final inventory synchronization where shown. Do not start another management-component operation while this task is running. If a subtask fails, open its details, fix the reported issue, and retry it before proceeding.

If Stage VCD_MIGRATOR precheck binaries eventually times out instead of progressing, review KB 452122. Broadcom identifies pod starvation and Fluentd readiness failures as causes of this specific precheck timeout; resolve the underlying health issue before retrying.

Verify the New Version

The supplied captures end while the upgrade is In Progress, so the final version still needs to be verified after the task completes.

Go to Build -> Lifecycle -> VCF Management -> Components, open the Migration Service Engine component, and verify that it reports Status: Running and version 9.1.1.0.25714559. Also review VCF Management -> Tasks for failed, partial, or stale tasks.

For a workload-migration environment, test the VCF Automation provider and tenant portals, confirm the migration service health, validate the VCD and vCenter connections, and run the supported migration prechecks before moving any workload. The vCenter migration service account must be a member of the SSO group SupervisorProviderAdministrators; if you add it after the connection was created, refresh the VCF Automation vCenter connection as described in KB 444854.

The supplied run is still in progress. Once the task reports Completed and the component is Running at the target build, the next management-component upgrade can proceed within the dependency order in the VCF 9.1.1 release notes.

Upgrading VCF Management Components to 9.1.1 All in One

Cosmin Trif — Mon, 14 Sep 2026 09:00:00 +0000

With VCF 9.1.1 released on September 3, 2026, I wanted to bring the management-service upgrades together in one place. I already wrote a separate walkthrough for each component, but following a collection of individual posts is not how I want to plan a maintenance window. This post is the all-in-one runbook I would use for a VCF 9.1.0.x fleet, including the VCD Migrator that was missing from my earlier set of guides.

VCF 9.1.1 is a maintenance release with an updated Bill of Materials (BOM). The official release notes say that a 9.1.0.x environment starts by patching Fleet Lifecycle. After that, the remaining components follow a small set of dependencies. The release notes also link to the VCF Upgrade Planning Tool, which is useful when the source environment is older than 9.1.0.x.

This article covers the VCF Management page in VCF Operations. It does not replace the supported upgrade path for a VCF 5.2.x or 9.0.x environment, the core SDDC upgrade order, or the migration workflow from older releases. For a fleet-managed 9.1.0.x maintenance patch, use VCF Management; Broadcom does not recommend the manual .PAK method for that case.

The Important Difference From the Older Guides

The VCF Operations page can show an Upgrade (ALL) action after the target version is selected. It is tempting to select every row and let the page run everything at once. Broadcom documents a 9.1 lifecycle issue where concurrent component runs can interfere with the plan records. A component can finish successfully but remain stuck as Ready for upgrade, with the same build on both sides of the upgrade path. That state can block later upgrades and has no customer-side database fix.

For that reason, this is an all-in-one article and execution plan, not a recommendation to launch every component concurrently. Select one component, run its prechecks, upgrade it, wait for the task to show Completed, confirm the version, and then continue. This also makes a failed task much easier to isolate.

What Gets Patched

The exact rows depend on which services are installed in each VCF instance. The build numbers below are the versions shown in my lab and are included to make the upgrade path easy to recognize. Confirm the target offered by your VCF Operations UI against the current 9.1.1 BOM.

Component	Lab source	Lab target	Detailed walkthrough
Fleet Lifecycle	9.1.0.0400.25570104	9.1.1.0.25713934	Fleet Lifecycle
VCF Operations	9.1.0.0400.25541561	9.1.1.0.25679751	Operations lab result and method caveat
VCF Services Runtime	9.1.0.0200.25555874	9.1.1.0.25714471	Services Runtime
VCF Automation	9.1.0.0200.25556825	9.1.1.0.25714559	VCF Automation
Migration Service Engine (VCD_MIGRATOR)	9.1.0.0200.25556825	9.1.1.0.25714559	Migration Service Engine
SDDC Lifecycle	9.1.0.0400.25570103	9.1.1.0.25713940	SDDC Lifecycle
Identity Broker	9.1.0.0100.25522734	9.1.1.0.25679886	Identity Broker
Salt RaaS	9.1.0.0100.25434834	9.1.1.0.25679895	Salt RaaS
Salt Master	9.1.0.0400.25544946	9.1.1.0.25679895	Salt Master
Log Management	9.1.0.0400.25544947	9.1.1.0.25679624	Log Management
Operations for Networks	9.1.0.0200.25517220	9.1.1.0.25682214	Operations for Networks
Real-Time Metrics Store	9.1.0.0200.25555874	9.1.1.0.25714471	Real-Time Metrics Store
Real-Time Metrics	9.1.0.0400.25544944	9.1.1.0.25679622	Real-Time Metrics
Telemetry	9.1.0.0.25181946	9.1.1.0.25671600	Telemetry

The BOM also lists Software Depot 9.1.1.0.25713941, Cloud Proxy 9.1.1.0.25679891, and License Server 9.1.1.0.25679819. Include them in the final inventory check. Cloud Proxy and License Server lifecycle is bundled with VCF Operations in the standard lifecycle workflow. Optional services may add more rows; the table above covers the component walkthroughs already published on this blog.

If the inventory includes Migration Service Engine, that is the VCD Migrator backend. VCF Operations labels the row Migration service engine, while the workflow and download tool use VCD_MIGRATOR and VCF_SERVICE_VCD_MIGRATION_BACKEND. Upgrading this component prepares the migration service; it does not start a VCD workload migration.

Before You Begin

This runbook assumes that the VCF instance is already on 9.1.0.x and that VCF Operations can see its management components. If the environment is on 5.2.x or 9.0.x, use the supported upgrade path first. The VCF 9.1 upgrade guidance covers the larger sequence: VCF Operations, SDDC Manager, VCF Management Services, and then the core domain components.

Before opening the upgrade page:

Check the source and target builds against the VCF Interoperability Matrix, the release notes, and the BOM. Do not force an upgrade when the target is not a supported path.
Configure and validate the backup target required by each component under Build -> Lifecycle -> VCF Management -> Backup & Restore. For file-based VCF Management services, an external SFTP server is the recommended target, and you should verify a fresh backup before patching. Use an image-based backup for VCF Operations and Operations for Networks. Keep the encryption passphrase available for a restore. Broadcom lists Telemetry and Real-Time Metrics as N/A for backup, and the runtime file-based backup covers service accounts only. Log Management backups exclude log data, which must be archived separately. Follow the component backup-method table; do not assume every row has an on-demand component backup.
Download all required binaries before starting. For the primary VCF instance, Broadcom’s required-binaries list includes Fleet Lifecycle, SDDC Lifecycle, VCF Services Runtime, Salt RaaS, Salt Master, Identity Broker, Software Depot, Telemetry, and License Server. Use the VCF Download Tool and binary-management documentation for disconnected environments.
Check VCF Operations, the VCF services runtime, and every hosted component for healthy nodes, disk, CPU, memory, DNS, certificates, and credentials. A full management-services node or volume can prevent staging; review the node-capacity guidance and volume-capacity guidance if alerts are present.
If you use custom VCF Automation profiles, review the cleanup procedure in KB 451147 before upgrading. Custom profiles from earlier 9.x releases can make the Automation upgrade fail.
Record the integrations and user-facing checks you will run afterward. Identity Broker affects SSO, Log Management affects ingestion, Operations for Networks affects network visibility, and Automation affects portals and deployments.
Plan a maintenance window. Do not start another lifecycle operation while the current component task is running.

The Dependency Order

The release notes give the mandatory boundaries. I use the following order for a maintenance window, while still checking the target and prechecks shown by VCF Operations:

Fleet Lifecycle must be patched first.
Run the VCF Operations appliance update by itself. For a fleet-managed 9.1.0.x environment, use the VCF Management lifecycle workflow; the PAK procedure below is included for supported legacy paths only.
Patch VCF Services Runtime before Identity Broker or Salt RaaS on the same VCF instance. I also keep Salt Master after the runtime so all Salt services are handled in the same dependency boundary.
Patch VCF Automation before Migration Service Engine (VCD_MIGRATOR), if it is installed.
If both Log Management and Operations for Networks are installed, I run Log Management to completion before Operations for Networks. This is my safe sequential choice; Broadcom documents a problem with running those operations in parallel in KB 452169.
Patch every remaining installed component one at a time. Wait for the overall task to show Completed, including inventory synchronization, and verify the component version before starting the next row. This sequential execution follows KB 453246.

Operations and Software Depot are isolated operations in this runbook because their tasks can block binary availability or other lifecycle work. The release notes remain the authority for any component or dependency not listed here.

Before Running the Component Steps

The shared preparation is already covered above. Before every individual row, return to Build -> Lifecycle -> VCF Management -> Upgrade, confirm the intended VCF instance and target, clear other selections, expand Check Required Binaries, and select exactly one component. Use Run Prechecks (1), open Precheck details, remediate failures, and proceed only when the row says Ready for upgrade. After clicking Upgrade, open Upgrade details, wait for Completed, then confirm Components -> Summary -> Running and the expected build. The sections below preserve the component-specific clicks, workflow details, and validation from the individual walkthroughs.

1. Fleet Lifecycle

Fleet Lifecycle is the required first operation. Its card has a dedicated target selector, so do not use the global management-component target for this row.

Checking for the Upgrade

To get started, log in to VCF Operations and go to Build -> Lifecycle -> VCF Management -> Upgrade.

The lifecycle metadata is normally synced automatically. If it has been a while since the last sync, we can trigger one manually. I usually perform a manual sync before starting an upgrade to make sure I have the latest metadata.

To do this, click on Sync in the top right corner and wait for the task to complete before selecting the new version.

In the capture above, both sides of the version arrow still show 9.1.0.0400.25570104. We need to change the Fleet Lifecycle target before clicking on Upgrade.

Selecting the Target Version

On the Fleet Lifecycle card, click on the … menu and select Select version. Use the menu on this card; the Change Target Version button below it controls the other VCF Management component targets.

The Fleet Lifecycle Component Target Version dialog opens. Select 9.1.1.0.25713934 and click on Set Target Version.

We can now see the upgrade path from 9.1.0.0400.25570104 to 9.1.1.0.25713934.

Click on Check Binary Availability and confirm that the required binary is available before proceeding. If it is missing, resolve the depot or download issue and run the check again.

Running the Upgrade

Once binary availability is confirmed, click on Upgrade. The card changes to Upgrade in progress. Click on Upgrade details to follow the task.

Here we can see the workflow setting the Fleet Lifecycle upgrade context and staging the Fleet Lifecycle plugin in VCF Services Runtime. In this capture, the first subtask has completed and staging is still in progress.

Wait for the workflow to finish. Review any failed task or precheck and resolve the reported issue before retrying the upgrade.

Verifying the New Version

Once the upgrade is complete, return to Build -> Lifecycle -> VCF Management -> Upgrade. Verify that the Fleet Lifecycle card shows Current version: 9.1.1.0.25713934.

We can also check the Tasks tab to verify that the upgrade workflow finished successfully. My final capture shows the last lifecycle metadata sync time as N/A. If an automatic sync has not run recently, we can use Sync before continuing with the other component upgrades.

One known issue to keep in mind: if you plan to scale VCF Services Runtime from Small to Small (High Availability), upgrade SDDC Lifecycle to 9.1.1 as well before doing that. The VCF Operations 9.1.1 release notes document a failure when Fleet Lifecycle is on 9.1.1 while SDDC Lifecycle is still on 9.1.0.

2. VCF Operations (PAK path when supported)

This is the VCF Operations appliance path from the earlier guide. Use it only when your supported source and deployment call for a PAK update. For a fleet-managed 9.1.0.x environment, use the VCF Management lifecycle operation and keep this section as a legacy-path reference.

Downloading the Upgrade PAK

To get started, log in to the Broadcom Support Portal and go to My Downloads -> VMware Cloud Foundation -> VMware Cloud Foundation 9 -> 9.1.1.0. Under VCF Operations, click View Group.

Read both agreements and accept the terms to enable the downloads.

Download Operations-Upgrade-9.1.1.0.25679887.pak. The portal also provides the checksums that we can use to validate the file after the download.

Checking the Cluster Before the Upgrade

Open the VCF Operations administration interface at https://<primary-node-fqdn>/admin and log in with the local admin account.

Go to System Status and make sure the cluster is Online and every node is Running. In my lab the starting node version was 9.1.0.0400.25541561.

Go to Software Update. The previously installed update in my lab was 9.1.0.0400.25541550. Click Install a Software Update.

Uploading the PAK File

Click Browse, select Operations-Upgrade-9.1.1.0.25679887.pak, and click Upload. Leave Install the PAK file even if it is already installed unchecked.

The upload can take some time because the PAK is just over 7 GB. Once it finishes, confirm that the signature is valid and that the version is 9.1.1.0.25679887, then click Next.

Review the End User License Agreement, select I accept the terms of this agreement, and click Next.

Review the update information and the software update best practices. This screen reminds us to have a backup or snapshots, run the pre-upgrade assessment, and remove the snapshots after the upgrade. Click Next.

On the last page, click Install. The installer restarts the cluster before copying the files, and the administration interface will become unavailable for a while.

Monitoring the Upgrade

After the administration interface comes back, log in again and go to Software Update to follow the progress. The workflow moves through 14 steps. In the capture below it is at 7 of 14 - Preapply Validated and is preparing for certificate renewal.

Once all 14 steps complete, the status changes to Applied and Cleaned. In my single-node lab the install took about 40 minutes after the PAK finished uploading.

Verifying the Upgrade

Go back to System Status and verify that the cluster is Online and every node is Running. The final node version in my lab is 9.1.1.0.25679751.

In the standard lifecycle workflow, cloud proxy and license server lifecycle is bundled with VCF Operations. Because this lab used the maintenance PAK route, verify both explicitly instead of assuming they were updated. The 9.1.1 release notes list cloud proxy build 25679891 and license server build 25679819. I also recommend checking that collections have resumed, integrations are healthy, dashboards load, and fresh metrics are coming in.

Don’t forget to remove the snapshots once everything has been validated. Since we are doing an upgrade, I also strongly recommend clearing the browser cache before using the new VCF Operations version.

3. VCF Services Runtime

Run this section after Fleet Lifecycle. The runtime must be at 9.1.1 before its dependent Identity Broker and Salt operations. Its file-based backup covers service accounts only, so retain the individual hosted-service recovery points as well.

Selecting the Target Version

To get started, log in to VCF Operations with an Administrator account and go to Build -> Lifecycle -> VCF Management -> Upgrade.

We can see that Fleet Lifecycle is already upgraded, but the management components still have 9.1.0.* selected as the target. If the new release is not available, use Sync to refresh the lifecycle metadata and wait for the task to complete.

Under Management Components, click on Select Version.

In the Set Target Version dialog, select 9.1.1.* from the VCF global version drop-down and click on Set Version.

Please note that this target applies to management components across all VCF instances. Setting the target does not start the upgrades; we still need to select the component to upgrade.

Running the Runtime Prechecks

Clear any existing component selections, then filter the list for runtime and select the VCF services runtime row for the instance you want to upgrade. In my lab this is instance-a.

Make sure only the intended runtime is selected. The buttons should show Run Prechecks (1) and Upgrade (1). Check that the upgrade path is 9.1.0.0200.25555874 -> 9.1.1.0.25714471.

Expand Check Required Binaries and confirm that the required binaries are available. Resolve any missing binaries before proceeding.

Click on Run Prechecks (1). Once the task completes, review Precheck details and resolve any errors before starting the upgrade, following the individual component upgrade procedure.

Here we can see the runtime row showing Ready for upgrade, with the Precheck details link available.

Starting the Upgrade

Once the prechecks have completed successfully, click on Upgrade on the runtime row.

The status changes to Upgrade in progress. We can follow the progress by clicking on Upgrade details.

The workflow starts by setting the runtime upgrade context and staging the runtime plugin. In this capture we can see Staging binaries followed by Running Component Stage Prechecks.

We now have to wait for the workflow to finish. It continues through runtime prechecks, package staging, upgrade preparation, the upgrade itself, and the final inventory sync.

If a task fails, open its details and resolve the reported issue before retrying. The 9.1.1 known issues also explain that a completed workflow can retain failed subtask attempts after successful retries. Review the final task status and component health when checking the result.

Verifying the Upgrade

Once the upgrade is complete, the workflow shows Completed. The final Inventory sync post VCF services runtime upgrade subtask also shows Completed.

In my lab the workflow started at 9:01 AM and completed at 2:46 PM on September 7, about 5 hours and 45 minutes. This is the total workflow time shown in my task, not a measurement of service downtime. Allow for your environment to take a different amount of time.

We can verify the installed version by going to Build -> Lifecycle -> VCF Management -> Components and opening VCF Services Runtime for the instance.

Under Summary, check that the status is Running and the version is 9.1.1.0.25714471.

Before moving on, open Services runtime health and check the nodes and hosted services for outstanding health issues. Verify the services you use, such as sign-in, log collection, and lifecycle operations, and confirm that backups are still working.

4. SDDC Lifecycle

Run this as a single component operation. If you plan to scale Services Runtime from Small to Small (High Availability), complete this upgrade before scaling.

Selecting SDDC Lifecycle

To get started, log in to VCF Operations with an Administrator account and go to Build -> Lifecycle -> VCF Management -> Upgrade.

The Target VCF version in my lab is already set to 9.1.1.* from the previous upgrade. If yours is still on 9.1.0.*, click on Select Version and set the target to 9.1.1.*, as covered in the runtime walkthrough.

Clear any existing component selections, filter the list for sddc, and select SDDC lifecycle for the instance you want to upgrade. In my lab this is instance-a. Make sure only the intended component is selected; the buttons should show Run Prechecks (1) and Upgrade (1).

Expand Check Required Binaries and resolve any missing binaries before proceeding. Check that the upgrade path is 9.1.0.0400.25570103 -> 9.1.1.0.25713940.

Running the Prechecks

Click on Run Prechecks (1). The row changes to Prechecks in progress.

Click on Precheck details to follow the workflow. The detail view shows the precheck context being set and the SDDC Lifecycle precheck binaries being staged.

In my lab the precheck started at 8:56 AM and completed at 9:11 AM on September 8. The final result was Passed, including the component package, vCenter, database upgrade, and single-component backup checks.

Once the prechecks pass, return to the upgrade list. The row should show Ready for upgrade.

Resolve any failed check before continuing, following Broadcom’s individual component upgrade procedure.

Starting the Upgrade

Click on Upgrade on the SDDC Lifecycle row.

The status changes to Upgrade in progress. Click on Upgrade details to follow the workflow.

The workflow sets the upgrade context, stages the SDDC Lifecycle plugin in VCF Services Runtime, runs the component prechecks, stages the package, prepares and performs the upgrade, and finishes with an inventory sync.

Wait for the workflow to finish. If a task fails, open its details, resolve the reported issue, and retry it before moving on.

Verifying the Upgrade

Once the upgrade is complete, the workflow shows Completed. In my lab all seven subtasks completed, including Inventory sync post SDDC lifecycle upgrade. The upgrade started at 9:15 AM and finished at 10:04 AM on September 8, about 49 minutes for the full workflow.

We can verify the installed version by going to Build -> Lifecycle -> VCF Management -> Components and opening SDDC Lifecycle for the instance.

Under Summary, check that the status is Running and the version is 9.1.1.0.25713940. Also confirm that it is managed by the expected VCF Services Runtime instance.

One known issue to keep in mind: if you plan to scale VCF Services Runtime from Small to Small (High Availability), upgrade SDDC Lifecycle to 9.1.1 before doing that. The VCF Operations 9.1.1 release notes document a failure when Fleet Lifecycle is on 9.1.1 while SDDC Lifecycle is still on 9.1.0.

SDDC Lifecycle in my lab is now on 9.1.1. We can continue with the remaining management components, following the release-specific dependencies above.

5. VCF Automation

Run this after the runtime required by your deployment and before Migration Service Engine. Take the VCF Automation backup first, and remove or remediate custom profiles from 9.0.1, 9.0.2.x, or 9.1.0.x by following KB 451147. Review the 9.1.1 behavior changes in the first subsection before starting.

A Few Things to Know About 9.1.1

VCF Automation 9.1.1 adds support for VLAN-backed VPCs consumed through VCF Automation. It also changes the default behavior for native public-cloud management: support for AWS, Azure, and GCP resources is deprecated and disabled by default in VM Apps organizations. If you use those capabilities, review Broadcom KB 448993 before upgrading so you understand the effect on existing deployments and how to restore the functionality.

The release also fixes several problems that are relevant to an upgrade window, including long waits with a generic timeout during the backup stage, mixed-case FQDN failures, services not recovering after a cluster power-on, and log buffers filling the logging disk. BYO Velero package installation is deprecated as well; the release notes recommend using the package deployed by VKS.

Selecting VCF Automation

The target version in my lab was already set to 9.1.1.*. If the target still shows 9.1.0.*, click Select Version, choose 9.1.1.*, and set the new target. If 9.1.1 is not listed, use Sync and wait for the lifecycle metadata task to finish.

Under Management Components, filter the list for automation and select the VCF Automation row for the VCF instance you want to upgrade. In my lab this was instance-a. Expand Check Required Binaries and resolve any missing binary before continuing.

The upgrade path should read 9.1.0.0200.25556825 -> 9.1.1.0.25714559. The screenshot below shows the target version and the VCF Automation row ready for the precheck workflow.

Running the Prechecks

Make sure only the intended VCF Automation component is selected. The buttons should show Run Prechecks (1) and Upgrade (1). Click Run Prechecks (1) and open Precheck details to follow the task.

The precheck workflow validates the package, the vCenter connection, the VCF services platform, and the component backup requirements. Review every result and remediate any failure before starting the upgrade.

When the precheck is complete, return to the upgrade list. The row should show Ready for upgrade. In my lab the selected row showed the expected source and target builds and the precheck link remained available for review.

Starting the Upgrade

Click Upgrade on the VCF Automation row. The status changes to Upgrade in progress. Click Upgrade details to follow the workflow.

The workflow stages the VCF Automation binaries in the VCF services runtime, runs the component-stage prechecks, and continues through the package staging and upgrade tasks. The details view in my run showed Stage VCF Automation precheck binaries in progress, followed by the component checks.

Wait for the task to finish. If a subtask fails, open its details, resolve the reported issue, and retry it before moving on. Do not start another management-component operation while this workflow is running.

Verifying the Upgrade

Once the task reports Completed, go to Build -> Lifecycle -> VCF Management -> Components and open VCF Automation for the upgraded instance.

In the component Summary, verify that the status is Running and that the version is 9.1.1.0.25714559. The final capture from my lab shows the upgraded VCF Automation instance running at the expected version.

After the component reports Running, test the provider and tenant portals, logins, cloud accounts, catalog requests, representative deployments, and any integrations that are important in your environment. Also check the VCF services runtime health and confirm that fresh lifecycle tasks and backups work as expected.

Once validation is complete, remove any temporary snapshots you created or expire backup artifacts according to your retention policy. I also recommend clearing the browser cache before using the updated VCF Automation and VCF Operations interfaces.

VCF Automation in my lab is now on 9.1.1.0.25714559. If this is part of a complete VCF 9.1.1 maintenance run, continue with the remaining components while following the dependency boundaries in the release notes.

6. Migration Service Engine (VCD Migrator)

Run this immediately after VCF Automation when the row is installed. VCF Operations calls it Migration service engine; its workflow token is VCD_MIGRATOR. Confirm the migration backend binary VCF_SERVICE_VCD_MIGRATION_BACKEND is available. If the service was uninstalled and reinstalled, check KB 453702 before proceeding.

Selecting the Migration Service Engine

The upgrade path should read 9.1.0.0200.25556825 -> 9.1.1.0.25714559.

Select the row. The action bar shows RUN PRECHECKS (1) and UPGRADE (1), and the row reports Ready for upgrade after the precheck has passed.

Run the Prechecks

Start the Upgrade

Click UPGRADE on the selected row. The status changes to Upgrade in progress and an Upgrade details link appears.

Verify the New Version

The supplied captures end while the upgrade is In Progress, so the final version still needs to be verified after the task completes.

7. Identity Broker

Run this only after the hosting VCF Services Runtime is on 9.1.1.

Selecting Identity Broker

Set the target VCF version to 9.1.1.* if it is not already selected. If the release is not listed, use Sync to refresh the lifecycle metadata and wait for that task to finish before checking again.

Filter the component list for identity and select Identity broker for the VCF instance you want to patch. In my lab the instance was instance-a. Expand Check Required Binaries and resolve any missing binary before continuing.

The upgrade path should read 9.1.0.0100.25522734 -> 9.1.1.0.25679886. The screenshot below shows Fleet Lifecycle on 9.1.1, the 9.1.1 target, and Identity Broker ready for upgrade.

Running the Prechecks

With only Identity Broker selected, click Run Prechecks (1). Open Precheck details and wait for the Identity broker Precheck Workflow to finish.

When the precheck completes, review the Prechecks tab and confirm that the overall result is Passed. In my run, the checks covered package staging, the vCenter connection, the database upgrade, the VCF services platform version, and the single-component backup requirement.

Return to the component list and confirm that Identity Broker is Ready for upgrade. Do not start the upgrade while the precheck is still running. If a check fails, open its details, fix the reported issue, and run the precheck again.

Starting the Upgrade

Click Upgrade on the Identity Broker row. The status changes to Upgrade in progress. Open Upgrade details to follow the workflow.

The workflow runs through these subtasks:

Set Identity Broker upgrade context for the workflow.
Stage the Identity Broker plugin in the VCF services runtime.
Run the Identity Broker prechecks.
Stage the Identity Broker package in the VCF services runtime.
Prepare Identity Broker for upgrade.
Perform the Identity Broker upgrade.
Run the inventory sync after the Identity Broker upgrade.

The task details show the plugin staging and component-stage prechecks while the upgrade is in progress.

The workflow in my lab started at 7:52 PM and completed at 9:18 PM, for a total workflow time of about 1 hour and 26 minutes. That is the task duration shown in my lab, not a promise about service downtime in another environment. Wait for the final inventory sync and confirm that the overall task is Completed.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open the Identity Broker component for the instance you upgraded.

Under Summary, verify that the status is Running and the version is 9.1.1.0.25679886. In my lab the deployment size was Small, it was managed by the VCF services runtime, and the managed link was VCF SSO.

After the component reports Running, validate the authentication path that matters in your environment:

Sign in to VCF Operations with the configured SSO identity provider.
Test a directory user and a group-based role assignment.
Confirm that the expected groups and permissions are still available.
Test representative VCF component logins and any applications that use the Identity Broker integration.
Check VCF Management -> Tasks for failed or partially completed tasks, and review VCF services runtime and Identity Broker health.

Treat the lifecycle task and the login checks as separate validations. A completed task confirms that the package workflow finished; successful SSO tests confirm that the broker is serving authentication correctly in your environment.

Once the component and authentication path have been validated, keep or expire the backup artifacts according to your retention policy. I also recommend clearing the browser cache before using the updated VCF Operations interface.

Identity Broker in my lab is now on 9.1.1.0.25679886. If this is part of a larger VCF 9.1.1 maintenance run, continue with the remaining components in the order and dependency boundaries documented in the VCF 9.1.1 release notes.

8. Salt RaaS

Run this only after the hosting VCF Services Runtime is on 9.1.1.

Selecting Salt RaaS

Set the target VCF version to 9.1.1.*. If the release is not listed, click Sync, wait for the lifecycle metadata task to complete, and check again. Setting the target only changes the available target; it does not start an upgrade.

Filter the component list for salt and select the Salt RaaS row for the VCF instance you want to patch. In my lab the instance is instance-a. Make sure only the intended component is selected, and expand Check Required Binaries to resolve any missing binary.

The upgrade path should read 9.1.0.0100.25434834 -> 9.1.1.0.25679895.

Running the Prechecks

With only Salt RaaS selected, click Run Prechecks (1). Open Precheck details and wait for the Salt RaaS Precheck Workflow to finish.

The first part of the workflow stages the precheck binaries. The task view reports the staging messages and the component stage precheck status while it runs.

The workflow then runs the Salt RaaS prechecks. Do not start the upgrade while this task is still running.

When the task completes, review the Prechecks tab and confirm that the overall result is Passed. In my run, the list included component package staging, package staging, Virtual Center, VMSP platform version, database upgrade, and single-component backup checks, all marked Passed.

Return to the component list and confirm that Salt RaaS is Ready for upgrade. If a check fails, open its details, fix the reported issue, and run the precheck again.

Starting the Upgrade

Click Upgrade on the Salt RaaS row. The status changes to Upgrade in progress. Open Upgrade details to follow the workflow.

The workflow runs through these subtasks:

Set Salt RaaS upgrade context for the workflow.
Stage the Salt RaaS plugin in the VCF services runtime.
Run the Salt RaaS prechecks.
Stage the Salt RaaS package in the VCF services runtime.
Prepare Salt RaaS for upgrade.
Perform the Salt RaaS upgrade.
Run the inventory sync after the Salt RaaS upgrade.

While the upgrade prechecks are running, the task details show the component upgrade precheck messages. Wait for the workflow to move through package staging, preparation, and the upgrade itself.

When the final inventory sync completes, confirm that the overall task status is Completed. The supplied captures contain separate precheck and upgrade task timestamps from the lab, so I am not treating them as a single downtime measurement.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open Salt RaaS for the instance you upgraded.

Under Summary, verify that the status is Running, the version is 9.1.1.0.25679895, and the component is managed by the expected VCF services runtime. In my lab the deployment size is Small.

Before moving on, review VCF Management -> Tasks for failed or partially completed tasks, check the VCF services runtime and Salt health, and confirm that the management-services backup still works. Also verify the Salt Master separately if it is installed; the RaaS upgrade does not prove that every Salt component is on 9.1.1.

VCF Salt RaaS in my lab is now on 9.1.1.0.25679895. We can continue with the remaining management components by following the dependencies in the VCF 9.1.1 release notes.

9. Salt Master

Run this after the runtime and keep it separate from other lifecycle tasks.

Selecting Salt Master

Set the target VCF version to 9.1.1.*. If the release is not listed, click Sync, wait for the lifecycle metadata task to complete, and check again.

Filter the component list for master and select the Salt master row for the VCF instance you want to patch. In my lab the instance was instance-a. Make sure only the intended component is selected. Expand Check Required Binaries and resolve any missing binary before continuing.

The upgrade path should read 9.1.0.0400.25544946 -> 9.1.1.0.25679895.

Running the Prechecks

With only Salt Master selected, click Run Prechecks (1). Open Precheck details and wait for the Salt master Precheck Workflow to finish.

When the precheck completes, review the Prechecks tab and confirm that the overall result is Passed. In my run, the checks included component package staging, package staging, the vCenter connection, the database upgrade, and the single-component backup requirement.

Return to the component list and confirm that Salt Master is Ready for upgrade. Do not start the upgrade while the precheck is still running. If a check fails, open its details, fix the reported issue, and run the precheck again.

Starting the Upgrade

Click Upgrade on the Salt Master row. The status changes to Upgrade in progress. Open Upgrade details to follow the workflow.

The workflow in my lab moved through these subtasks:

Set Salt master upgrade context for the workflow.
Stage the Salt master plugin in the VCF services runtime.
Run Salt master prechecks.
Stage the Salt master package in the VCF services runtime.
Prepare Salt master for upgrade.
Perform the Salt master upgrade.
Run the inventory sync after the Salt master upgrade.

The workflow then advances through the Salt master prechecks, package staging, and preparation steps.

The task details show the package staging, prechecks, preparation, and upgrade subtasks. Wait for the final inventory sync and confirm that the overall task is Completed.

In my lab the workflow started at 6:51 AM and completed at 7:42 AM on September 9, for a total workflow time of about 51 minutes. That is the duration shown by my task, not a promise about service downtime in another environment.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open Salt Master for the instance you upgraded.

Under Summary, verify that the status is Running and the version is 9.1.1.0.25679895. In my lab the deployment size was Small and it was managed by the VCF services runtime.

Before moving on, review VCF Management -> Tasks for failed or partially completed tasks, check the VCF services runtime and Salt health, and confirm that the management-services backup still works. If Salt RaaS is also present, verify its version and patch it only after its hosting runtime meets the 9.1.1 dependency.

10. Log Management

Run Log Management to completion before Operations for Networks when both are installed. Log data is not included in the component backup, so retain a separate archive.

Selecting Log Management

The target in my lab is already 9.1.1.*. If the target is still on an older release, click Select Version, choose 9.1.1.*, and apply the target before selecting the component. If the page shows a warning that VCF Operations must be patched independently, finish that patch and wait for it to succeed before continuing with the other management components.

Filter the component list for log, select Log management, and make sure the intended instance is selected. In my lab the instance is instance-a. Expand Check Required Binaries and resolve any missing binary before continuing.

The upgrade path should read 9.1.0.0400.25544947 -> 9.1.1.0.25679624. The screenshot below shows the target version, the selected Log Management instance, and the Ready for upgrade state.

Running the Prechecks

With only Log Management selected, click Run Prechecks (1). Follow the task by opening Precheck details.

The precheck workflow in my lab completed successfully in about 14 minutes. It passed the package staging, vCenter, database upgrade, and single-component backup checks.

Do not start the upgrade until the precheck status is Passed. If a check fails, open its details, remediate the reported issue, and run the precheck again.

Starting the Upgrade

Return to the component list and click Upgrade on the Log Management row. The row changes to Upgrade in progress. Click Upgrade details to follow the workflow.

The workflow runs through these subtasks:

Set Log Management upgrade context for the workflow.
Stage the Log Management plugin in VCF services runtime.
Run the Log Management prechecks.
Stage the Log Management package in VCF services runtime.
Prepare Log Management for upgrade.
Perform the Log Management upgrade.
Run the post-upgrade inventory sync.

The workflow started at 10:53 AM in my lab. The task took about 1 hour and 11 minutes, completing at 12:04 PM. That is the total workflow time shown in my task, not a promise about service downtime in another environment. Wait for the final inventory sync and confirm that the overall task is Completed.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open the Log Management component for the instance you upgraded.

Under Summary, verify that the status is Running, the version is 9.1.1.0.25679624, and the component is managed by the expected VCF services runtime. In my lab the deployment size is Small with one replica.

After the component reports Running, validate the parts of the service that matter in your environment:

Open Operate -> Logs and run a known query.
Confirm that new events are arriving from representative vSphere, ESXi, and application sources.
Check dashboards, alerts, notification targets, and any custom integrations.
Verify that any custom log forwarding configuration still points to the correct Log Management instance.

9.1.1 Changes to Keep in Mind

11. Operations for Networks

Run this after Log Management has completed when both components are installed. For an XL deployment, if the system precheck reports system.health.status.check, apply KB 454602: add the required 1 TB disk, let the appliance detect it, and rerun the precheck.

Selecting VCF Operations for Networks

Expand Check Required Binaries, resolve any missing binary, and filter the component list for networks. Select the VCF Operations for networks row for the instance you want to patch. In my lab the instance is instance-a.

The upgrade path should read 9.1.0.0200.25517220 -> 9.1.1.0.25682214. The screenshot below shows Fleet Lifecycle on 9.1.1, the 9.1.1 target, the selected Networks instance, and the Ready for upgrade state.

Running the Prechecks

With only VCF Operations for Networks selected, click Run Prechecks (1). Open Precheck details and wait for the workflow to finish.

The precheck in my lab started at 8:30 PM and completed at 8:34 PM. The result was Passed. Platform, collector, system, and appliance prechecks all passed; the appliance checks contained nine individual checks.

Return to the component list and confirm that the Networks row is Ready for upgrade. Do not start the upgrade while the precheck is still running. If a check fails, open its details, fix the reported issue, and run the precheck again.

Starting the Upgrade

Click Upgrade on the Networks row. The status changes to Upgrade in progress. Open Upgrade details to follow the workflow.

The workflow runs through these subtasks:

Run Component Upgrade Prechecks.
Prepare Component for Upgrade.
Stage Upgrade Binaries.
Perform Component Upgrade.
Run the Inventory Sync Post Upgrade.

The Perform Component Upgrade task is the part that takes the longest. The workflow in my lab started at 9:02 PM and completed at 11:11 PM, for a total task time of about 2 hours and 9 minutes. That is the duration shown by my task, not a promise about service downtime in another environment.

Wait for the final inventory sync and confirm that the overall task is Completed. The completed workflow also refreshes the component endpoint and checks whether the VCF Operations for Networks service account needs to be created.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open VCF Operations for Networks for the instance you upgraded.

Under Summary, verify that the status is Running and the version is 9.1.1.0.25682214. In my lab the deployment size is XL and the summary shows Telemetry: Deactivated. That value is a configuration state displayed by the component; review it against your organization’s telemetry policy rather than assuming the upgrade changed it.

After the component reports Running, validate the parts of the service that matter in your environment:

Confirm that representative vSphere, NSX, and physical-network data sources are connected and collecting.
Run a known search query and open a recent flow or path result.
Check dashboards, alerts, notification targets, and any custom integrations.
Verify that the collectors are healthy and that new flow data continues to arrive.
Review VCF Management -> Tasks for failed or partially completed tasks.

With an integrated Networks instance on 9.1.1 or later, VCF Operations uses the VIM Adapter path for certificate collection. This removes the older same-node placement dependency described in KB 454096. Check the certificate status after the upgrade so that you know the new collection path is working.

If Fleet Lifecycle still shows the upgrade as in progress after the appliance is already reporting the new version, do not immediately repeat the upgrade. KB 432678 describes the case where the appliance does not report back to Fleet Manager; after confirming the new version, the documented recovery is to reboot the VCF Fleet Manager appliance and allow the next inventory sync to clear the stale task state.

Keep or expire the backup artifacts according to your retention policy. VCF Operations for Networks in my lab is now on 9.1.1.0.25682214. If this is part of a larger VCF 9.1.1 maintenance run, continue with the remaining components in the order and dependency boundaries documented in the VCF 9.1.1 release notes.

12. Real-Time Metrics Store

This is a separate component from Real-Time Metrics. Patch and validate the store row independently.

Selecting Real-Time Metrics Store

Set the target VCF version to 9.1.1.* if it is not already selected. Expand Check Required Binaries and resolve any missing binary before continuing.

Filter the component list for metric, select Real-time metrics store, and confirm that the intended instance is selected. In my lab the instance is instance-a. The upgrade path should read 9.1.0.0200.25555874 -> 9.1.1.0.25714471.

Select the row and click Run Prechecks (1). The selected row shows the component and the same source and target builds before the precheck starts.

Running the Prechecks

Open the task details and wait for the Real-time metrics store Precheck Workflow to finish. The workflow runs the component upgrade prechecks before the upgrade is allowed to start.

When the precheck completes, return to the component list and confirm that the row is Ready for upgrade. Do not click Upgrade while the precheck is still running. If a check fails, open its details, fix the reported issue, and run the precheck again.

Starting the Upgrade

Click Upgrade on the Real-Time Metrics Store row. The row changes to Upgrade in progress. Open Upgrade details to follow the workflow.

The workflow runs through these subtasks:

Set Real-Time Metrics Store upgrade context for the workflow.
Stage the Real-Time Metrics Store plugin in the VCF services runtime.
Run the Real-Time Metrics Store prechecks.
Stage the Real-Time Metrics Store package in the VCF services runtime.
Prepare Real-Time Metrics Store for upgrade.
Perform the Real-Time Metrics Store upgrade.
Run the inventory sync after the Real-Time Metrics Store upgrade.

The task in my lab started at 2:45 PM and completed at 3:29 PM, for a total workflow time of about 44 minutes. That is the duration shown by my task, not a promise about service downtime in another environment. Wait for the final inventory sync and confirm that the overall task is Completed.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open Real-Time Metrics Store for the instance you upgraded.

Under Summary, verify that the status is Running and the version is 9.1.1.0.25714471. In my lab the deployment size is Small, it is managed by the VCF services runtime, and telemetry is Deactivated.

13. Real-Time Metrics

Patch this row independently from Real-Time Metrics Store and validate fresh data after the task completes.

Selecting Real-Time Metrics

Set the target VCF version to 9.1.1.* if it is not already selected. If the page shows that VCF Operations itself must be patched first, finish that operation and wait for it to complete before continuing.

Filter the component list for real or metrics and select Real-time metrics. In my lab the instance was instance-a. Expand Check Required Binaries and resolve any missing binary before continuing.

The upgrade path should read 9.1.0.0400.25544944 -> 9.1.1.0.25679622. The screenshot below shows Fleet Lifecycle already at 9.1.1, the 9.1.1 target, and Real-Time Metrics ready for upgrade.

Running the Prechecks

With only Real-Time Metrics selected, run the prechecks for that component. Open the task details and wait for the Real-time metrics Precheck Workflow to finish.

The precheck in my lab completed successfully. It checked the component package staging, vCenter, database upgrade, and single-component backup requirements.

Do not start the upgrade until the precheck result is Passed. If a check fails, open its details, fix the reported issue, and run the precheck again.

Starting the Upgrade

Return to the component list and click Upgrade on the Real-Time Metrics row. The row changes to Upgrade in progress. Open Upgrade details to follow the workflow.

The workflow runs through these subtasks:

Set Real-Time Metrics upgrade context for the workflow.
Stage the Real-Time Metrics plugin in the VCF services runtime.
Run the Real-Time Metrics prechecks.
Stage the Real-Time Metrics package in the VCF services runtime.
Prepare Real-Time Metrics for upgrade.
Perform the Real-Time Metrics upgrade.
Run the inventory sync after the Real-Time Metrics upgrade.

The first part of the workflow runs the component prechecks and reports the result in the task panel.

The task in my lab started at 1:25 PM and completed at 2:12 PM, for a total workflow time of about 47 minutes. That is the duration shown by my task and is not a promise about service downtime in another environment. Wait for the final inventory sync and confirm that the overall task is Completed.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open the Real-Time Metrics component you upgraded.

Under Summary, verify that the status is Running and the version is 9.1.1.0.25679622. In my lab the deployment size was Small and the component was managed by the VCF services runtime.

After the component reports Running, validate the data path that matters in your environment:

Open Operate -> Real-Time Metrics and query a known resource.
Confirm that fresh samples are arriving and that the expected time range is available.
Check the dashboards, saved views, Top-N views, custom PromQL queries, and any integrations that use the Real-Time Metrics data.
Confirm that related vCenter, ESX, vSAN, and NSX resources still show current data where your environment collects those metrics.

14. Telemetry

Telemetry is listed as N/A in Broadcom’s component backup-method table; keep the supporting VCF Operations and management-service recovery points current.

Selecting Telemetry

Filter the component list for telemetry and select the Telemetry row for the VCF instance you want to patch. In my lab the instance was instance-a. Expand Check Required Binaries and resolve any missing binary before continuing.

The upgrade path should read 9.1.0.0.25181946 -> 9.1.1.0.25671600. The screenshot below shows Fleet Lifecycle on 9.1.1, the 9.1.1 target, and Telemetry ready for upgrade.

Running the Prechecks

With only Telemetry selected, click Run Prechecks (1). Open the task details and wait for the Telemetry Precheck Workflow to finish.

When the precheck completes, review Prechecks and confirm that the result is Passed. The checks in my run covered package staging, the vCenter connection, the database upgrade, and the lifecycle backup precheck shown by the UI. Telemetry itself is listed as N/A for backup in the current backup-method table.

Return to the component list and confirm that Telemetry is Ready for upgrade. Do not start the upgrade while the precheck is still running. If a check fails, open its details, fix the reported issue, and run the precheck again.

Starting the Upgrade

Click Upgrade on the Telemetry row. The status changes to Upgrade in progress. Open Upgrade details to follow the workflow.

The task details can be used to watch the plugin staging and component stage prechecks:

The overall workflow then moves through these subtasks:

Set Telemetry upgrade context for the workflow.
Run Telemetry prechecks.
Stage the Telemetry package in the VCF services runtime.
Prepare Telemetry for upgrade.
Perform the Telemetry upgrade.
Run the inventory sync after the Telemetry upgrade.

The task in my lab started at 5:15 PM and completed at 5:59 PM, for a total workflow time of about 44 minutes. That is the duration shown by my task, not a promise about service downtime in another environment. Wait for the final inventory sync and confirm that the overall task is Completed.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open the Telemetry component for the instance you upgraded.

Under Summary, verify that the status is Running and the version is 9.1.1.0.25671600. In my lab the deployment size was Small, it was managed by the VCF services runtime, and the summary showed Telemetry: Deactivated.

Post-Upgrade Validation

Once all selected components report 9.1.1:

Check Build -> Lifecycle -> VCF Management -> Components for a consistent inventory and no component still showing an old target.
Review Build -> Lifecycle -> Tasks for failed, partial, or stale tasks. If a component is already on the target but remains stuck as Ready for upgrade, do not edit the lifecycle database; open Broadcom Support and reference KB 453246.
Test SSO through Identity Broker, VCF Operations logins and dashboards, Log Management ingestion, Operations for Networks collection, Automation portals and a representative deployment, Salt health, Telemetry behavior, and the services-runtime health dashboard.
If VCF Operations was upgraded, check the precheck result for affected Management Packs. KB 454432 lists packs that need a 9.1.1-compatible update, and KB 454434 covers custom packs built with an older MP Builder.
Confirm that a new management-services backup completes and that the backup artifacts are retained according to your policy.
If the VCF Operations Build -> Lifecycle page is blank or spins after an appliance update, test an incognito window or clear the browser cache. Broadcom tracks that behavior in KB 441205.

And with that, we have one repeatable plan for the VCF Management 9.1.1 maintenance window. The UI still gives us a single place to see every component, every precheck, and every task, while the execution stays within the current Broadcom guidance for 9.1.1.

Upgrading VCF Automation to 9.1.1 Step by Step

Cosmin Trif — Sun, 13 Sep 2026 09:30:00 +0000

With VCF 9.1.1 released on September 3, 2026, I continued upgrading the management components in my lab. In this post I will go over upgrading VCF Automation from 9.1.0.0200 to 9.1.1.0 through VCF Operations.

VCF 9.1.1 is a maintenance release focused mostly on supportability improvements. The VCF 9.1.1 release notes are the source for the release scope, patch order, and known issues. The component release notes for VCF Automation 9.1.1 list build 25714559.

A Few Things to Know About 9.1.1

Versions in This Upgrade

These are the versions shown in the VCF Operations UI in my lab:

Component	Before	After
VCF Automation	9.1.0.0200.25556825	9.1.1.0.25714559

The target build matches the VCF Automation entry in the VCF 9.1.1 Bill of Materials.

Before You Begin

For an existing 9.1.0.x environment, upgrade Fleet Lifecycle to 9.1.1 first, before patching any other VCF component. After that, continue to follow the component dependencies in the 9.1.1 release notes. In my lab, Fleet Lifecycle was already on 9.1.1.

Before starting:

Verify that a supported backup target is configured and reachable under Build -> Lifecycle -> VCF Management -> Backup & Restore. Use the target required by the component backup method. Keep the backup encryption passphrase available for a restore. The VCF backup and restore documentation describes the supported methods.
Take an on-demand backup of the VCF Automation component. Go to Backup & Restore -> Backup -> Backup Now, select the VCF instance and VCF Automation, start the backup, and verify that it completes successfully.
Confirm that the 9.1.1 binaries are available in the configured software depot. For an offline or disconnected environment, prepare the binaries with the VCF Download Tool.
Check the VCF services runtime and VCF Automation health before starting. Make sure DNS resolution is stable and that no other lifecycle operation is running. The individual-component procedure allows only one upgrade or patch operation at a time.
Remove or remediate custom profiles before starting. Broadcom documents that custom profiles from VCF Automation 9.0.1, 9.0.2.x, or 9.1.0.x can cause the upgrade to fail; follow KB 451147 for the cleanup procedure.
Plan a maintenance window. VCF Automation services can restart during the workflow, so test the provider and tenant portals, integrations, and representative deployments afterward.

Selecting VCF Automation

The upgrade path should read 9.1.0.0200.25556825 -> 9.1.1.0.25714559. The screenshot below shows the target version and the VCF Automation row ready for the precheck workflow.

Running the Prechecks

Starting the Upgrade

Click Upgrade on the VCF Automation row. The status changes to Upgrade in progress. Click Upgrade details to follow the workflow.

Verifying the Upgrade

Once the task reports Completed, go to Build -> Lifecycle -> VCF Management -> Components and open VCF Automation for the upgraded instance.

Upgrading VCF Operations for Networks to 9.1.1 Step by Step

Cosmin Trif — Fri, 11 Sep 2026 09:00:00 +0000

With VCF 9.1.1 released on September 3, 2026, I continued patching the management services in my lab. In this post I will go over upgrading VCF Operations for Networks from 9.1.0.0200 to 9.1.1.0 through VCF Operations.

The VCF 9.1.1 release notes are the source for the release scope, upgrade sequence, dependencies, and known issues. In my lab, the target VCF Operations for Networks build was 9.1.1.0.25682214.

VCF Operations for Networks was formerly known as Aria Operations for Networks and vRealize Network Insight. In VCF 9.1 it is a separate appliance managed from the VCF Operations Fleet Lifecycle workflow. This walkthrough covers one 9.1.0.x maintenance upgrade. If you are still on Aria Operations for Networks 6.x, I covered upgrading to 6.14 via an upgrade bundle and upgrading to 6.14 via Aria Suite Lifecycle. Moving from 6.14 into VCF 9.x is a separate migration path, so follow the applicable VCF upgrade procedure first.

Versions in This Upgrade

These are the versions reported by the VCF Operations UI in my lab:

Component	Before	After
VCF Operations for Networks	9.1.0.0200.25517220	9.1.1.0.25682214

Before You Begin

For an existing 9.1.0.x environment, upgrade Fleet Lifecycle to 9.1.1.0 before any other VCF component. The screenshot in this post shows Fleet Lifecycle already on 9.1.1.0.25713934. After that prerequisite is complete, patch the remaining components according to the dependencies in the VCF 9.1.1 release notes.

The page can also show a warning that VCF Operations must be patched independently from the other management components. If that warning is present, finish the VCF Operations patch and wait for it to complete before starting this upgrade.

Before starting:

Verify that a supported backup target is configured and reachable under Build -> Lifecycle -> VCF Management -> Backup & Restore. Use the target required by the component backup method. Keep the backup encryption passphrase available for a restore. The VCF backup and restore documentation describes the supported configuration.
Take or verify the supported image-based backup of the VCF Operations for Networks appliance before patching. Do not treat a backup that is still running as a completed recovery point.
Confirm that lifecycle metadata is current and that the 9.1.1 binaries are available in the configured software depot. For a disconnected environment, prepare the binaries with the VCF Download Tool.
Make sure no other management-component upgrade or patch operation is running. I run one component at a time so that a failure is easier to isolate.
Record the network data sources, integrations, dashboards, and alerts you need to test afterward, and plan a maintenance window.

The appliance in my lab is XL. Before running the precheck, confirm that the appliance has enough disk capacity for its brick size. If an XL deployment fails the system precheck with system.health.status.check, Broadcom’s KB 454602 documents adding a 1 TB disk to the platform VM, waiting for the appliance to detect it, and then running the precheck again.

One more 9.1.1 sequencing detail is easy to miss: do not install Log Management and VCF Operations for Networks in parallel. The release notes document a condition where the platform can be disrupted and the Networks task can remain stuck for more than three hours. Run those component operations sequentially.

Selecting VCF Operations for Networks

Running the Prechecks

With only VCF Operations for Networks selected, click Run Prechecks (1). Open Precheck details and wait for the workflow to finish.

Starting the Upgrade

Click Upgrade on the Networks row. The status changes to Upgrade in progress. Open Upgrade details to follow the workflow.

The workflow runs through these subtasks:

Run Component Upgrade Prechecks.
Prepare Component for Upgrade.
Stage Upgrade Binaries.
Perform Component Upgrade.
Run the Inventory Sync Post Upgrade.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open VCF Operations for Networks for the instance you upgraded.

After the component reports Running, validate the parts of the service that matter in your environment:

Confirm that representative vSphere, NSX, and physical-network data sources are connected and collecting.
Run a known search query and open a recent flow or path result.
Check dashboards, alerts, notification targets, and any custom integrations.
Verify that the collectors are healthy and that new flow data continues to arrive.
Review VCF Management -> Tasks for failed or partially completed tasks.

Upgrading VCF Salt RaaS to 9.1.1 Step by Step

Cosmin Trif — Thu, 10 Sep 2026 23:30:00 +0000

With VCF 9.1.1 released on September 3, 2026, I wanted to continue patching the management services in my lab. This post is a follow-up to my older SaltStack Config 8.12.1 guide and covers upgrading VCF Salt RaaS from 9.1.0.0100 to 9.1.1 through VCF Operations.

VCF Salt is the current product name for the Salt services that were previously presented as SaltStack Config or VMware Aria Automation Config. The VCF 9.1.1 release notes and the VCF Operations 9.1.1 release notes are the references I used for the target build and upgrade dependencies.

This walkthrough covers a 9.1.0.x maintenance upgrade of one Salt RaaS instance. If you are coming from an older VCF or Aria release, follow the applicable migration or major-version procedure before using these steps.

Versions in This Upgrade

These are the versions shown by the VCF Operations UI in my lab:

Component	Before	After
Salt RaaS	9.1.0.0100.25434834	9.1.1.0.25679895

Before You Begin

For an existing 9.1.0.x environment, upgrade Fleet Lifecycle to 9.1.1.0 before any other VCF component. Broadcom also requires the VCF services runtime that hosts Salt RaaS to be on 9.1.1 before upgrading the service. In my lab, Fleet Lifecycle and the services runtime were already updated before I started this operation.

Before starting:

Verify that a supported backup target is configured and reachable under Build -> Lifecycle -> VCF Management -> Backup & Restore. Use the target required by the component backup method. Keep the backup encryption passphrase available for a restore. The VCF management backup and restore documentation describes the supported workflow.
Take an on-demand component backup and confirm that it completed successfully before patching. A backup configuration by itself does not prove that a recent restore point exists.
Check the VCF services runtime and Salt health, including CPU, memory, and disk utilization. Salt services can restart during maintenance, so plan a maintenance window.
Confirm that lifecycle metadata is current and that the 9.1.1 Salt RaaS binary is available in the assigned software depot. For a disconnected environment, prepare the binaries with the VCF Download Tool. Broadcom’s required-binaries guidance lists Salt RaaS and Salt Master among the binaries needed for the primary VCF instance.
Make sure no other management-component operation is running. Follow the individual VCF management component upgrade procedure and resolve any missing binary before proceeding.

The VCF Operations page can also show a warning that VCF Operations must be patched independently. If that warning is present, finish that patch and wait for it to succeed before starting Salt RaaS.

Selecting Salt RaaS

The upgrade path should read 9.1.0.0100.25434834 -> 9.1.1.0.25679895.

Running the Prechecks

With only Salt RaaS selected, click Run Prechecks (1). Open Precheck details and wait for the Salt RaaS Precheck Workflow to finish.

The first part of the workflow stages the precheck binaries. The task view reports the staging messages and the component stage precheck status while it runs.

The workflow then runs the Salt RaaS prechecks. Do not start the upgrade while this task is still running.

Return to the component list and confirm that Salt RaaS is Ready for upgrade. If a check fails, open its details, fix the reported issue, and run the precheck again.

Starting the Upgrade

Click Upgrade on the Salt RaaS row. The status changes to Upgrade in progress. Open Upgrade details to follow the workflow.

The workflow runs through these subtasks:

Set Salt RaaS upgrade context for the workflow.
Stage the Salt RaaS plugin in the VCF services runtime.
Run the Salt RaaS prechecks.
Stage the Salt RaaS package in the VCF services runtime.
Prepare Salt RaaS for upgrade.
Perform the Salt RaaS upgrade.
Run the inventory sync after the Salt RaaS upgrade.

While the upgrade prechecks are running, the task details show the component upgrade precheck messages. Wait for the workflow to move through package staging, preparation, and the upgrade itself.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open Salt RaaS for the instance you upgraded.

VCF Salt RaaS in my lab is now on 9.1.1.0.25679895. We can continue with the remaining management components by following the dependencies in the VCF 9.1.1 release notes.

Upgrading VCF Salt Master to 9.1.1 Step by Step

Cosmin Trif — Wed, 09 Sep 2026 12:00:00 +0000

With VCF 9.1.1 released on September 3, 2026, I continued patching the management services in my lab. In this post I will go over upgrading the VCF Salt Master from 9.1.0.0400 to 9.1.1 through VCF Operations.

The VCF 9.1.1 release notes are the source for the release scope and patch dependencies. The VCF Operations 9.1.1 release notes list Salt Master and Salt RaaS at target build 25679895.

This walkthrough covers a 9.1.0.x to 9.1.1 maintenance upgrade of one Salt Master instance. If you are starting from an older VCF or VMware Aria release, follow the applicable VCF upgrade or migration procedure first.

Versions in This Upgrade

These are the versions reported by the VCF Operations UI in my lab:

Component	Before	After
Salt Master	9.1.0.0400.25544946	9.1.1.0.25679895

Before You Begin

For an existing 9.1.0.x environment, patch Fleet Lifecycle to 9.1.1.0 before any other VCF component. Before patching Salt RaaS, Broadcom requires the respective VCF management services runtime that hosts it to be on 9.1.1. In my lab, Fleet Lifecycle and the services runtime were already upgraded before I started this Salt Master operation.

Before starting:

Verify that the VCF management-services backup configuration is present and reachable under Build -> Lifecycle -> VCF Management -> Backup & Restore. Take an on-demand component backup and verify that it completed successfully. Keep the backup encryption passphrase available for a restore. The VCF management backup and restore documentation describes the supported workflow.
Check the VCF services runtime and hosted-service health, including CPU, memory, and disk utilization. Salt Master is hosted by that runtime.
Confirm that lifecycle metadata is current and that the 9.1.1 binaries are available in the assigned software depot. For a disconnected environment, prepare the binaries with the VCF Download Tool.
Make sure no other management-component operation is running. The software depot must also be usable because patching it makes the binaries unavailable to other component operations until it finishes.
Plan a maintenance window. Salt services can restart while the workflow is running.

The VCF Operations page may also display a warning that VCF Operations must be patched independently. If that warning is present, wait for that patch to complete before starting Salt Master.

Selecting Salt Master

Set the target VCF version to 9.1.1.*. If the release is not listed, click Sync, wait for the lifecycle metadata task to complete, and check again.

The upgrade path should read 9.1.0.0400.25544946 -> 9.1.1.0.25679895.

Running the Prechecks

With only Salt Master selected, click Run Prechecks (1). Open Precheck details and wait for the Salt master Precheck Workflow to finish.

Starting the Upgrade

Click Upgrade on the Salt Master row. The status changes to Upgrade in progress. Open Upgrade details to follow the workflow.

The workflow in my lab moved through these subtasks:

Set Salt master upgrade context for the workflow.
Stage the Salt master plugin in the VCF services runtime.
Run Salt master prechecks.
Stage the Salt master package in the VCF services runtime.
Prepare Salt master for upgrade.
Perform the Salt master upgrade.
Run the inventory sync after the Salt master upgrade.

The workflow then advances through the Salt master prechecks, package staging, and preparation steps.

The task details show the package staging, prechecks, preparation, and upgrade subtasks. Wait for the final inventory sync and confirm that the overall task is Completed.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open Salt Master for the instance you upgraded.

Under Summary, verify that the status is Running and the version is 9.1.1.0.25679895. In my lab the deployment size was Small and it was managed by the VCF services runtime.

Before moving on, review VCF Management -> Tasks for failed or partially completed tasks, check the VCF services runtime and Salt health, and confirm that the management-services backup still works. If Salt RaaS is also present, verify its version and patch it only after its hosting runtime meets the 9.1.1 dependency.

The Salt Master in my lab is now on 9.1.1.0.25679895. We can continue with the remaining management components by following the dependencies in the VCF 9.1.1 release notes.

Upgrading VCF Identity Broker to 9.1.1 Step by Step

Cosmin Trif — Wed, 09 Sep 2026 03:00:00 +0000

With VCF 9.1.1 released on September 3, 2026, I continued patching the management services in my lab. This post is a follow-up to my VCF 9.1 management services upgrade walkthrough and covers VCF Identity Broker through VCF Operations.

The VCF 9.1.1 release notes are the source for the release scope, upgrade sequence, dependencies, and known issues. The VCF Operations 9.1.1 release notes list the Identity Broker target build as 25679886.

In VCF 9.1, Identity Broker is a VCF management service hosted by the VCF services runtime. The supported lifecycle workflow is Build -> Lifecycle -> VCF Management -> Upgrade. This walkthrough covers a 9.1.0.x maintenance upgrade. If you are coming from an older VCF or VMware Identity Manager deployment, follow the applicable migration or upgrade procedure first; this is not a replacement for that transition workflow.

Versions in This Upgrade

These are the versions reported by the VCF Operations UI in my lab:

Component	Current Version	Target Version
Identity Broker	9.1.0.0100.25522734	9.1.1.0.25679886

The target build matches the Identity Broker entry in the VCF Operations 9.1.1 release notes.

Before You Begin

For an existing 9.1.0.x environment, upgrade Fleet Lifecycle to 9.1.1.0 before any other VCF component. The release notes also require VCF Services Runtime to be upgraded to 9.1.1 before Identity Broker or Salt RaaS. In my lab Fleet Lifecycle and the runtime were already on 9.1.1 when I ran this operation. I documented the runtime upgrade in Upgrading VCF Services Runtime to 9.1.1 Step by Step.

Before starting:

Verify that the VCF management-services backup configuration is present and reachable under Build -> Lifecycle -> VCF Management -> Backup & Restore. Keep the backup encryption passphrase available for a restore.
Take an on-demand component backup and verify that it completed successfully before patching Identity Broker. The VCF management backup and restore documentation describes the supported workflow.
Check VCF services runtime and hosted-service health before starting, including node CPU, memory, and disk utilization. Identity Broker depends on that runtime for its control plane and storage.
Confirm that lifecycle metadata is current and that the 9.1.1 binaries are available in the configured software depot. For a disconnected environment, prepare the binaries with the VCF Download Tool.
Make sure no other management-component upgrade or patch operation is running. The individual-component procedure says another management-component operation cannot run while a component operation is in progress.
Plan a maintenance window. Identity Broker provides SSO, so expect authentication to be unavailable or interrupted while its services are restarted. Record the SSO login and directory integrations you want to test afterward.

The VCF Operations page can also display a warning that VCF Operations must be patched independently from the other management components. If that warning is present, finish that patch and wait for it to complete before starting Identity Broker.

Selecting Identity Broker

The upgrade path should read 9.1.0.0100.25522734 -> 9.1.1.0.25679886. The screenshot below shows Fleet Lifecycle on 9.1.1, the 9.1.1 target, and Identity Broker ready for upgrade.

Running the Prechecks

With only Identity Broker selected, click Run Prechecks (1). Open Precheck details and wait for the Identity broker Precheck Workflow to finish.

Starting the Upgrade

Click Upgrade on the Identity Broker row. The status changes to Upgrade in progress. Open Upgrade details to follow the workflow.

The workflow runs through these subtasks:

Set Identity Broker upgrade context for the workflow.
Stage the Identity Broker plugin in the VCF services runtime.
Run the Identity Broker prechecks.
Stage the Identity Broker package in the VCF services runtime.
Prepare Identity Broker for upgrade.
Perform the Identity Broker upgrade.
Run the inventory sync after the Identity Broker upgrade.

The task details show the plugin staging and component-stage prechecks while the upgrade is in progress.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open the Identity Broker component for the instance you upgraded.

After the component reports Running, validate the authentication path that matters in your environment:

Sign in to VCF Operations with the configured SSO identity provider.
Test a directory user and a group-based role assignment.
Confirm that the expected groups and permissions are still available.
Test representative VCF component logins and any applications that use the Identity Broker integration.
Check VCF Management -> Tasks for failed or partially completed tasks, and review VCF services runtime and Identity Broker health.

Upgrading VCF Telemetry to 9.1.1 Step by Step

Cosmin Trif — Tue, 08 Sep 2026 21:30:00 +0000

With VCF 9.1.1 released on September 3, 2026, I continued patching the management services in my lab. In this post I will go over upgrading VCF Telemetry from 9.1.0.0 to 9.1.1.0 through VCF Operations.

The VCF 9.1.1 release notes are the source for the release scope, upgrade sequence, dependencies, and known issues. The VCF Operations 9.1.1 release notes list the Telemetry target build as 25671600.

Telemetry is a VCF management service hosted by the VCF services runtime. The supported lifecycle workflow is Build -> Lifecycle -> VCF Management -> Upgrade. This walkthrough covers one 9.1.0.x to 9.1.1 maintenance upgrade. If you are coming from an older VCF or Aria release, follow the applicable VCF upgrade procedure first.

Versions in This Upgrade

These are the versions reported by the VCF Operations UI in my lab:

Component	Before	After
Telemetry	9.1.0.0.25181946	9.1.1.0.25671600

The target build matches the Telemetry entry in the VCF Operations 9.1.1 release notes.

Before You Begin

For an existing 9.1.0.x environment, upgrade Fleet Lifecycle to 9.1.1 first. In my lab it was already running 9.1.1.0.25713934. After that prerequisite is complete, patch the remaining management components according to their release-note dependencies.

The VCF Operations page can also display a warning that VCF Operations must be patched independently from the other management components. If that warning is present, finish the VCF Operations patch and wait for it to complete before starting Telemetry.

Before starting:

Verify the supporting management-component backup configuration under Build -> Lifecycle -> VCF Management -> Backup & Restore and keep the encryption passphrase available for a restore. The VCF backup documentation describes the supported methods.
The current VCF backup-method table lists Telemetry as N/A. Keep the VCF Operations image-based backup and the backups of the supporting management services current; do not assume that Telemetry creates a standalone backup artifact. Review the VCF management backup and restore documentation for the supported methods.
Confirm that lifecycle metadata is current and that the 9.1.1 binaries are available in the assigned software depot. For a disconnected environment, prepare the binaries with the VCF Download Tool.
Make sure no other management-component upgrade or patch operation is running. I run one component at a time so that a failure is easier to isolate.
Plan a maintenance window and check the VCF services runtime health before starting.

Selecting Telemetry

The upgrade path should read 9.1.0.0.25181946 -> 9.1.1.0.25671600. The screenshot below shows Fleet Lifecycle on 9.1.1, the 9.1.1 target, and Telemetry ready for upgrade.

Running the Prechecks

With only Telemetry selected, click Run Prechecks (1). Open the task details and wait for the Telemetry Precheck Workflow to finish.

Starting the Upgrade

Click Upgrade on the Telemetry row. The status changes to Upgrade in progress. Open Upgrade details to follow the workflow.

The task details can be used to watch the plugin staging and component stage prechecks:

The overall workflow then moves through these subtasks:

Set Telemetry upgrade context for the workflow.
Run Telemetry prechecks.
Stage the Telemetry package in the VCF services runtime.
Prepare Telemetry for upgrade.
Perform the Telemetry upgrade.
Run the inventory sync after the Telemetry upgrade.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open the Telemetry component for the instance you upgraded.

The Telemetry: Deactivated value is a configuration state shown by the component summary. If your organization uses telemetry reporting, review that setting against your policy after the upgrade rather than assuming it changed as part of the package update.

Finally, review VCF Management -> Tasks for failed or partially completed tasks, check the VCF services runtime and Telemetry health, and confirm that the management-services backup still works. Keep or expire the backup artifacts according to your retention policy.

Telemetry in my lab is now on 9.1.1.0.25671600. If this is part of a larger VCF 9.1.1 maintenance run, continue with the remaining components in the order and dependency boundaries documented in the VCF 9.1.1 release notes.

Upgrading VCF Real-Time Metrics Store to 9.1.1 Step by Step

Cosmin Trif — Tue, 08 Sep 2026 20:00:00 +0000

The VCF 9.1.1 release notes are the source for the release scope, upgrade sequence, dependencies, and known issues. The VCF Operations 9.1.1 release notes list the Real-Time Metrics Store target build as 25714471.

The Real-Time Metrics Store is its own VCF management component. It is separate from the Real-Time Metrics component, even though both appear in the same VCF Management list. The supported lifecycle workflow is Build -> Lifecycle -> VCF Management -> Upgrade. This walkthrough covers a 9.1.0.x to 9.1.1 maintenance patch; an environment coming from an older VCF or Aria release should follow the applicable VCF upgrade procedure first.

Versions in This Upgrade

These are the versions reported by the VCF Operations UI in my lab:

Component	Current Version	Target Version
Real-Time Metrics Store	9.1.0.0200.25555874	9.1.1.0.25714471

The target build matches the Real-Time Metrics Store entry in the VCF Operations 9.1.1 release notes.

Before You Begin

For an existing 9.1.0.x environment, update Fleet Lifecycle to 9.1.1.0 before patching the other VCF components. The capture from my lab shows Fleet Lifecycle already on 9.1.1.0.25713934. After that prerequisite is complete, patch the remaining components according to their release-note dependencies. I ran this store upgrade by itself so the task and validation were easy to follow.

Before starting:

Verify that the VCF management-services backup configuration is present and reachable under Build -> Lifecycle -> VCF Management -> Backup & Restore.
The current VCF backup-method table does not list a standalone backup method for Real-Time Metrics Store. Keep the VCF Operations image-based backup and the backups of the supporting management services current, and use the lifecycle precheck as the final gate.
Confirm that lifecycle metadata is current and that the 9.1.1 binaries are available in the configured software depot. If the depot is offline, prepare the binaries with the VCF Download Tool.
Make sure no other upgrade or patch operation is running. Run the Real-Time Metrics Store upgrade separately from the Real-Time Metrics upgrade and any other management-component patch.
Plan a maintenance window and note the Real-Time Metrics queries, dashboards, and integrations you want to test afterward.

If VCF Operations displays the warning that it must be patched independently from the other management components, finish that VCF Operations patch and wait for it to complete before continuing.

Selecting Real-Time Metrics Store

Set the target VCF version to 9.1.1.* if it is not already selected. Expand Check Required Binaries and resolve any missing binary before continuing.

Select the row and click Run Prechecks (1). The selected row shows the component and the same source and target builds before the precheck starts.

Running the Prechecks

Open the task details and wait for the Real-time metrics store Precheck Workflow to finish. The workflow runs the component upgrade prechecks before the upgrade is allowed to start.

Starting the Upgrade

Click Upgrade on the Real-Time Metrics Store row. The row changes to Upgrade in progress. Open Upgrade details to follow the workflow.

The workflow runs through these subtasks:

Set Real-Time Metrics Store upgrade context for the workflow.
Stage the Real-Time Metrics Store plugin in the VCF services runtime.
Run the Real-Time Metrics Store prechecks.
Stage the Real-Time Metrics Store package in the VCF services runtime.
Prepare Real-Time Metrics Store for upgrade.
Perform the Real-Time Metrics Store upgrade.
Run the inventory sync after the Real-Time Metrics Store upgrade.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open Real-Time Metrics Store for the instance you upgraded.

The store is a backend component, so validate the data path through the Real-Time Metrics experience that uses it:

Open Operate -> Real-Time Metrics and query a known resource.
Confirm that fresh samples are arriving and that the expected time range is available.
Check dashboards, saved views, Top-N views, custom PromQL queries, and any integrations that depend on Real-Time Metrics data.
Confirm that representative vCenter, ESXi, vSAN, and NSX resources still show current data where your environment collects those metrics.

Treat the lifecycle task and the data check as separate validations. A completed task confirms that the package workflow finished; fresh samples confirm that the store is serving data in your environment.

Once the component and data path have been validated, review the supporting VCF Operations backup according to your retention policy. I also recommend clearing the browser cache before using the updated VCF Operations interface.

Real-Time Metrics Store in my lab is now on 9.1.1.0.25714471. If this is part of a larger VCF 9.1.1 maintenance run, continue with the remaining components in the order and dependency boundaries documented in the VCF 9.1.1 release notes.

Upgrading VCF Real-Time Metrics to 9.1.1 Step by Step

Cosmin Trif — Tue, 08 Sep 2026 18:00:00 +0000

With VCF 9.1.1 released on September 3, 2026, I wanted to continue patching the management services in my lab. This post is a follow-up to my VCF 9.1 management services upgrade walkthrough and focuses on Real-Time Metrics through VCF Operations.

VCF 9.1.1 is a maintenance release focused mostly on improving product supportability. The VCF 9.1.1 release notes include the Bill of Materials, upgrade sequence, dependencies, known issues, and the component build numbers. The VCF Operations 9.1.1 release notes list Real-Time Metrics at build 25679622.

In VCF 9.1, Real-Time Metrics is a VCF management service hosted by the VCF services runtime. The supported lifecycle workflow is under Build -> Lifecycle -> VCF Management -> Upgrade. This walkthrough covers one 9.1.0.x management-component patch. An environment coming from an older VCF or Aria release should follow the applicable upgrade path in the VCF documentation first.

Versions in This Upgrade

These are the versions reported by the VCF Operations UI in my lab:

Component	Current Version	Target Version
Real-Time Metrics	9.1.0.0400.25544944	9.1.1.0.25679622

The target build matches the Real-Time Metrics entry in the VCF Operations 9.1.1 release notes.

The Real-Time Metrics Store is listed as a separate VCF management component with its own 9.1.1 build (25714471). This post covers the Real-Time Metrics component shown in the screenshots; patch the store separately when it is part of your maintenance plan. I documented that workflow in Upgrading VCF Real-Time Metrics Store to 9.1.1 Step by Step.

Before You Begin

For a 9.1.0.x environment, patch Fleet Lifecycle to 9.1.1.0 before any other VCF component. Once Fleet Lifecycle is on 9.1.1.0, the release notes allow the remaining components to be patched according to their dependencies. My Fleet Lifecycle component was already on 9.1.1.0 when I ran this operation.

Before starting:

Verify that the VCF management-services backup configuration is present and reachable under Build -> Lifecycle -> VCF Management -> Backup & Restore.
The current VCF backup-method table lists Real-Time Metrics as N/A. Keep the VCF Operations image-based backup and the backups of the supporting management services current; do not assume that Real-Time Metrics creates a standalone backup artifact.
Confirm that the lifecycle metadata is current and that the 9.1.1.0 binaries are available in the configured software depot. If the depot is offline, prepare the binaries with the VCF Download Tool.
Make sure no other upgrade or patch operation is running. VCF Operations allows only one management-component patch operation at a time.
Plan a maintenance window and note the Real-Time Metrics resources, dashboards, or queries you want to test afterward.

Selecting Real-Time Metrics

The upgrade path should read 9.1.0.0400.25544944 -> 9.1.1.0.25679622. The screenshot below shows Fleet Lifecycle already at 9.1.1, the 9.1.1 target, and Real-Time Metrics ready for upgrade.

Running the Prechecks

With only Real-Time Metrics selected, run the prechecks for that component. Open the task details and wait for the Real-time metrics Precheck Workflow to finish.

The precheck in my lab completed successfully. It checked the component package staging, vCenter, database upgrade, and single-component backup requirements.

Do not start the upgrade until the precheck result is Passed. If a check fails, open its details, fix the reported issue, and run the precheck again.

Starting the Upgrade

Return to the component list and click Upgrade on the Real-Time Metrics row. The row changes to Upgrade in progress. Open Upgrade details to follow the workflow.

The workflow runs through these subtasks:

Set Real-Time Metrics upgrade context for the workflow.
Stage the Real-Time Metrics plugin in the VCF services runtime.
Run the Real-Time Metrics prechecks.
Stage the Real-Time Metrics package in the VCF services runtime.
Prepare Real-Time Metrics for upgrade.
Perform the Real-Time Metrics upgrade.
Run the inventory sync after the Real-Time Metrics upgrade.

The first part of the workflow runs the component prechecks and reports the result in the task panel.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open the Real-Time Metrics component you upgraded.

After the component reports Running, validate the data path that matters in your environment:

Open Operate -> Real-Time Metrics and query a known resource.
Confirm that fresh samples are arriving and that the expected time range is available.
Check the dashboards, saved views, Top-N views, custom PromQL queries, and any integrations that use the Real-Time Metrics data.
Confirm that related vCenter, ESX, vSAN, and NSX resources still show current data where your environment collects those metrics.

The VCF Operations 9.1.1 release notes do not call out a Real-Time Metrics-specific UI change in this patch. Treat the component task result and the post-upgrade data check as separate validations: a completed lifecycle task confirms the package workflow, while fresh samples confirm that collection is working for your environment.

Once the component and data collection have been validated, review the supporting VCF Operations backup according to your retention policy. I also recommend clearing the browser cache before using the updated VCF Operations interface.

Real-Time Metrics in my lab is now on 9.1.1.0.25679622. If this is part of a larger VCF 9.1.1 maintenance run, continue with the remaining components in the order and dependency boundaries documented in the VCF 9.1.1 release notes.

Upgrading VCF Log Management to 9.1.1 Step by Step

Cosmin Trif — Tue, 08 Sep 2026 16:30:00 +0000

VCF 9.1.1 is a maintenance release focused mostly on supportability improvements. The main VCF 9.1.1 release notes and the VCF Operations 9.1.1 release notes are the references I used for this upgrade.

In VCF 9.1, Log Management is a VCF management service hosted on the VCF services runtime. The supported lifecycle workflow is therefore in VCF Operations under Build -> Lifecycle -> VCF Management -> Upgrade. This walkthrough covers a 9.1.0.x maintenance upgrade; an environment coming from an older VCF or Aria release should follow the matching Log Management upgrade procedure first.

Versions in This Upgrade

These are the versions reported by the VCF Operations UI in my lab:

Component	Current Version	Target Version
Log Management	9.1.0.0400.25544947	9.1.1.0.25679624

The target build is also listed in the VCF Operations 9.1.1 release notes.

Before You Begin

For an existing 9.1.0.x environment, patch Fleet Lifecycle to 9.1.1.0 before any other VCF component. After Fleet Lifecycle is updated, the release notes allow the remaining components to be patched according to the documented dependencies. I ran this Log Management operation by itself so that the task and validation were easy to follow.

Before starting:

Verify that a supported backup target is configured and reachable under Build -> Lifecycle -> VCF Management -> Backup & Restore. Use the target required by the component backup method. Keep the backup encryption passphrase available for a restore.
Take an on-demand component backup and verify that it completed successfully before patching Log Management. Log data is not included in that backup, so archive it separately according to your retention policy.
Confirm that the lifecycle metadata is current and that the required 9.1.1 binaries are available in the configured software depot. If the depot is offline, prepare the binaries with the VCF Download Tool.
Make sure no other upgrade or patch operation is running. The individual-component procedure says another component cannot be upgraded or patched while an operation is in progress.
Plan a maintenance window and record the Log Management integrations and log sources you need to test afterward.

There is also a 9.1.1 known issue when Log Management and VCF Operations for networks are installed in parallel: the platform can be disrupted, causing Real-time Metrics to fail and the Operations for networks task to remain stuck for more than three hours. Install those components sequentially instead.

Selecting Log Management

The upgrade path should read 9.1.0.0400.25544947 -> 9.1.1.0.25679624. The screenshot below shows the target version, the selected Log Management instance, and the Ready for upgrade state.

Running the Prechecks

With only Log Management selected, click Run Prechecks (1). Follow the task by opening Precheck details.

The precheck workflow in my lab completed successfully in about 14 minutes. It passed the package staging, vCenter, database upgrade, and single-component backup checks.

Do not start the upgrade until the precheck status is Passed. If a check fails, open its details, remediate the reported issue, and run the precheck again.

Starting the Upgrade

Return to the component list and click Upgrade on the Log Management row. The row changes to Upgrade in progress. Click Upgrade details to follow the workflow.

The workflow runs through these subtasks:

Set Log Management upgrade context for the workflow.
Stage the Log Management plugin in VCF services runtime.
Run the Log Management prechecks.
Stage the Log Management package in VCF services runtime.
Prepare Log Management for upgrade.
Perform the Log Management upgrade.
Run the post-upgrade inventory sync.

Verifying the New Version

Go to Build -> Lifecycle -> VCF Management -> Components and open the Log Management component for the instance you upgraded.

After the component reports Running, validate the parts of the service that matter in your environment:

Open Operate -> Logs and run a known query.
Confirm that new events are arriving from representative vSphere, ESXi, and application sources.
Check dashboards, alerts, notification targets, and any custom integrations.
Verify that any custom log forwarding configuration still points to the correct Log Management instance.

9.1.1 Changes to Keep in Mind

The release notes call out a few Log Management changes that are easy to miss during validation:

The Additional Storage Required metric and its related symptoms, alerts, and dashboards were removed because the old value could report a misleading storage shortfall when no retention period was defined.
The Server Side Encryption field was removed from the Add New Storage screen. AWS S3 uses its default AES-256 behavior; for non-AWS S3-compatible storage, configure bucket-level encryption on the storage server itself.
If a Log Management Disaster Recovery restore leaves the Log Analysis page showing Unable to access logs due to user permissions, the documented workaround is to restart the Log Management service through Fleet Lifecycle using the component Stop / Start action.

Once the component and log sources have been validated, keep or expire the backup artifacts according to your retention policy. I also recommend clearing the browser cache before using the updated VCF Operations interface.

Log Management in my lab is now on 9.1.1. If this is part of a larger VCF 9.1.1 maintenance run, continue with the remaining components in the order and dependency boundaries documented in the VCF 9.1.1 release notes.

Upgrading VCF SDDC Lifecycle to 9.1.1 Step by Step

Cosmin Trif — Tue, 08 Sep 2026 12:00:00 +0000

With VCF Services Runtime upgraded to 9.1.1, the next component I wanted to upgrade in my lab was SDDC Lifecycle. In this post I will go over upgrading it from 9.1.0.0400 to 9.1.1.0 through VCF Operations.

VCF 9.1.1 was released on September 3, 2026. This is a maintenance release focused mostly on supportability improvements. The release notes can be found here.

Before You Begin

For an existing 9.1.0.x environment, upgrade Fleet Lifecycle to 9.1.1 first, before any other VCF component. In my lab it is already on 9.1.1.0.25713934. Continue to follow the release-specific dependencies in the 9.1.1 release notes when planning the remaining components.

Before starting:

Verify that a supported backup target is configured and reachable under Build -> Lifecycle -> VCF Management -> Backup & Restore. Use the target required by the component backup method. Keep the encryption passphrase available for a restore. The configuration steps are here.
Take an on-demand backup. Go to Backup & Restore -> Backup -> Backup Now, select the VCF instance and SDDC Lifecycle, and verify that the backup completes successfully. Review the supported backup methods.
Make sure the required upgrade binaries are available through the assigned depot. For offline or disconnected environments, prepare them with the VCF Download Tool using the binary management documentation.

I ran this as a single component operation and waited for it to complete before starting another management-service operation. That keeps the workflow easy to follow and avoids competing lifecycle tasks during the maintenance window.

Here are the versions from my lab:

Component	Before	After
SDDC Lifecycle	9.1.0.0400.25570103	9.1.1.0.25713940

The target version and build match the VCF 9.1.1 Bill of Materials.

Selecting SDDC Lifecycle

To get started, log in to VCF Operations with an Administrator account and go to Build -> Lifecycle -> VCF Management -> Upgrade.

Expand Check Required Binaries and resolve any missing binaries before proceeding. Check that the upgrade path is 9.1.0.0400.25570103 -> 9.1.1.0.25713940.

Running the Prechecks

Click on Run Prechecks (1). The row changes to Prechecks in progress.

Click on Precheck details to follow the workflow. The detail view shows the precheck context being set and the SDDC Lifecycle precheck binaries being staged.

Once the prechecks pass, return to the upgrade list. The row should show Ready for upgrade.

Resolve any failed check before continuing, following Broadcom’s individual component upgrade procedure.

Starting the Upgrade

Click on Upgrade on the SDDC Lifecycle row.

The status changes to Upgrade in progress. Click on Upgrade details to follow the workflow.

Wait for the workflow to finish. If a task fails, open its details, resolve the reported issue, and retry it before moving on.

Verifying the Upgrade

We can verify the installed version by going to Build -> Lifecycle -> VCF Management -> Components and opening SDDC Lifecycle for the instance.

Under Summary, check that the status is Running and the version is 9.1.1.0.25713940. Also confirm that it is managed by the expected VCF Services Runtime instance.

SDDC Lifecycle in my lab is now on 9.1.1. We can continue with the remaining management components, following the release-specific dependencies above.

Upgrading VCF Services Runtime to 9.1.1 Step by Step

Cosmin Trif — Mon, 07 Sep 2026 18:30:00 +0000

With Fleet Lifecycle upgraded to 9.1.1, the next component I wanted to upgrade in my lab was VCF Services Runtime. In this post I will go over upgrading it from 9.1.0.0200 to 9.1.1.0 through VCF Operations.

VCF 9.1.1 was released on September 3, 2026. The release notes can be found here. The runtime fixes listed in the VCF Operations release notes include improvements for mixed-case FQDNs, services recovering after a cluster power-on, and log buffers filling the logging disk.

Before You Begin

For an existing 9.1.0.x environment, upgrade Fleet Lifecycle to 9.1.1 first, before any other VCF component. Broadcom also requires the hosting runtime to be upgraded before the dependent Identity Broker and Salt RaaS upgrades to 9.1.1. The release-specific order is documented here.

Before starting:

Verify that a supported backup target is configured and reachable under Build -> Lifecycle -> VCF Management -> Backup & Restore. Use the target required by the component backup method. This is a prerequisite for patching VCF management services. Check the configuration status and keep the encryption passphrase available for a restore. The configuration steps are here.
Take an on-demand backup before the upgrade. Go to Backup & Restore -> Backup -> Backup Now, select the VCF instance and component, and verify that the backup completes. Include the runtime and the hosted services that support backup in your recovery plan. Broadcom lists the runtime’s file-based backup as covering service accounts only; it does not replace the individual service backups. Review the supported backup methods.
Check the runtime and hosted-service health before starting, including node CPU, memory, and disk utilization. Plan a maintenance window: hosted services can restart during maintenance. Broadcom describes these checks in the VCF Management Services health documentation.
Make sure the required binaries are available through the assigned software depot. For offline or disconnected environments, prepare them with the VCF Download Tool using the binary management documentation.

For this walkthrough we will upgrade one runtime instance and let it finish before starting another management-service operation. If VCF Operations itself is being patched, wait for that patch to complete first, as the banner in the screenshot below instructs. Also wait for any Software Depot patch to finish so the upgrade binaries are available.

Here are the versions from my lab:

Component	Before	After
VCF Services Runtime	9.1.0.0200.25555874	9.1.1.0.25714471

Fleet Lifecycle was already on 9.1.1.0.25713934. Both 9.1.1 build numbers match the VCF 9.1.1 Bill of Materials.

Selecting the Target Version

To get started, log in to VCF Operations with an Administrator account and go to Build -> Lifecycle -> VCF Management -> Upgrade.

Under Management Components, click on Select Version.

In the Set Target Version dialog, select 9.1.1.* from the VCF global version drop-down and click on Set Version.

Please note that this target applies to management components across all VCF instances. Setting the target does not start the upgrades; we still need to select the component to upgrade.

Running the Runtime Prechecks

Clear any existing component selections, then filter the list for runtime and select the VCF services runtime row for the instance you want to upgrade. In my lab this is instance-a.

Make sure only the intended runtime is selected. The buttons should show Run Prechecks (1) and Upgrade (1). Check that the upgrade path is 9.1.0.0200.25555874 -> 9.1.1.0.25714471.

Expand Check Required Binaries and confirm that the required binaries are available. Resolve any missing binaries before proceeding.

Click on Run Prechecks (1). Once the task completes, review Precheck details and resolve any errors before starting the upgrade, following the individual component upgrade procedure.

Here we can see the runtime row showing Ready for upgrade, with the Precheck details link available.

Starting the Upgrade

Once the prechecks have completed successfully, click on Upgrade on the runtime row.

The status changes to Upgrade in progress. We can follow the progress by clicking on Upgrade details.

The workflow starts by setting the runtime upgrade context and staging the runtime plugin. In this capture we can see Staging binaries followed by Running Component Stage Prechecks.

We now have to wait for the workflow to finish. It continues through runtime prechecks, package staging, upgrade preparation, the upgrade itself, and the final inventory sync.

Verifying the Upgrade

Once the upgrade is complete, the workflow shows Completed. The final Inventory sync post VCF services runtime upgrade subtask also shows Completed.

We can verify the installed version by going to Build -> Lifecycle -> VCF Management -> Components and opening VCF Services Runtime for the instance.

Under Summary, check that the status is Running and the version is 9.1.1.0.25714471.

The runtime in my lab is now on 9.1.1. We can continue with the remaining management components, following the release-specific dependencies above. Upgrading the runtime does not by itself confirm that every hosted component is on 9.1.1; check each component’s version separately.

Upgrading VCF Operations Fleet Lifecycle to 9.1.1 Step by Step

Cosmin Trif — Sun, 06 Sep 2026 09:00:00 +0000

With the release of VCF 9.1.1 on September 3, 2026, I wanted to get Fleet Lifecycle in my lab upgraded. This is a maintenance release focused mostly on supportability improvements. The release notes can be found here.

In this post I will go over upgrading Fleet Lifecycle through VCF Operations, from 9.1.0.0400 to 9.1.1.0.

Before You Begin

For an existing 9.1.0.x environment, Broadcom requires us to upgrade Fleet Lifecycle to 9.1.1.0 before any other VCF component. Make sure to follow the 9.1.1 release-specific dependencies when planning the rest of the upgrade.

Before starting:

Verify that a supported backup target is configured and reachable. An external SFTP server is recommended for the file-based management-service backups. Configure it under Build -> Lifecycle -> VCF Management -> Backup & Restore, following the SFTP backup location documentation. Keep the backup encryption passphrase available for a restore.
Take an on-demand backup of Fleet Lifecycle from Backup & Restore -> Backup -> Backup Now. Select the VCF instance and component, start the backup, and verify that it completed successfully.
Confirm that the configured depot can supply the upgrade binaries. If you use an offline or disconnected depot, prepare the required binaries with the VCF Download Tool using the binary management documentation.

Here are the versions from my lab:

Component	Before	After
Fleet Lifecycle	9.1.0.0400.25570104	9.1.1.0.25713934

The target build also matches the VCF 9.1.1 Bill of Materials.

Checking for the Upgrade

To get started, log in to VCF Operations and go to Build -> Lifecycle -> VCF Management -> Upgrade.

To do this, click on Sync in the top right corner and wait for the task to complete before selecting the new version.

In the capture above, both sides of the version arrow still show 9.1.0.0400.25570104. We need to change the Fleet Lifecycle target before clicking on Upgrade.

Selecting the Target Version

The Fleet Lifecycle Component Target Version dialog opens. Select 9.1.1.0.25713934 and click on Set Target Version.

We can now see the upgrade path from 9.1.0.0400.25570104 to 9.1.1.0.25713934.

Click on Check Binary Availability and confirm that the required binary is available before proceeding. If it is missing, resolve the depot or download issue and run the check again.

Running the Upgrade

Once binary availability is confirmed, click on Upgrade. The card changes to Upgrade in progress. Click on Upgrade details to follow the task.

Wait for the workflow to finish. Review any failed task or precheck and resolve the reported issue before retrying the upgrade.

Verifying the New Version

Once the upgrade is complete, return to Build -> Lifecycle -> VCF Management -> Upgrade. Verify that the Fleet Lifecycle card shows Current version: 9.1.1.0.25713934.

And with that we are finished upgrading Fleet Lifecycle to 9.1.1. We can now continue with the remaining VCF components following the dependencies in the 9.1.1 release notes.

Upgrading VCF Operations to 9.1.1 Using a .PAK File

Cosmin Trif — Thu, 03 Sep 2026 06:50:00 +0000

With the release of VMware Cloud Foundation 9.1.1 on September 3, 2026, I wanted to get my VCF Operations lab upgraded. This is a maintenance release focused mostly on supportability improvements. The VCF 9.1.1 release notes can be found here, and the VCF Operations release notes are here.

In this post I will go over upgrading VCF Operations from 9.1.0.0400 to 9.1.1 using the upgrade PAK file. If you are still on an older release, I also covered upgrading VCF Operations to 9.0.1 using a PAK file. That is a separate walkthrough, not a required intermediate upgrade.

Important: Broadcom does not recommend using the PAK method for maintenance upgrades in a fleet-managed VCF 9.1.0.x environment. In that case, upgrade Fleet Lifecycle to 9.1.1 first and use Build -> Lifecycle -> VCF Management -> Upgrade. I used the manual PAK workflow in my lab, and this post only covers the VCF Operations appliance. The screenshots document that lab result; they are not a replacement for the official component order or evidence that Fleet Lifecycle can be skipped. The PAK method remains the documented path when upgrading from Aria Operations 8.x or VCF Operations 9.0.x to 9.1.

What Is New in VCF Operations 9.1.1

A few changes in this release stood out to me:

SDDC Manager log collection can now be managed from VCF Operations.
A network proxy can be configured when deploying a new cloud proxy from the OVA.
The VMware Salt for VCF Components API is now available for managing configuration across VCF components.
Active Directory lookup, password management, and certificate management now cover more users, accounts, and VCF components.

The release also fixes problems with mixed-case FQDNs during upgrade operations, the UI not loading when NTP is out of sync, services not recovering after a cluster power-on, and log buffers filling the logging disk. Broadcom also published a separate VCF Operations 9.1.1 fixed-CVE workbook.

Versions Used in This Upgrade

The PAK file and the VCF Operations node use different build numbers. This is expected.

Item	Before	After
Installed update package	9.1.0.0400.25541550	9.1.1.0.25679887
VCF Operations node	9.1.0.0400.25541561	9.1.1.0.25679751

In my case the PAK file was Operations-Upgrade-9.1.1.0.25679887.pak, and the download was 7.03 GB.

Before You Begin

Before starting the upgrade:

Review the release notes and verify the supported upgrade path.
Confirm that every VCF Operations node is online and healthy and that DNS and NTP are working correctly.
Run the pre-upgrade assessment and review the results.
Back up any customized content that you need to preserve.
Take the VCF Operations cluster offline and snapshot every cluster node without virtual machine memory and without quiescing the guest file system. Broadcom documents the full process here. Bring the cluster online again before starting the upgrade.
Plan for downtime. The VCF Operations cluster restarts and remains unavailable during the update.

There is a known 9.1.1 issue where the Management Pack compatibility precheck can show raw resource keys and JSON. If that happens, download the APUAT support-bundle HTML report from the same precheck run to see the readable results.

Downloading the Upgrade PAK

To get started, log in to the Broadcom Support Portal and go to My Downloads -> VMware Cloud Foundation -> VMware Cloud Foundation 9 -> 9.1.1.0. Under VCF Operations, click View Group.

Read both agreements and accept the terms to enable the downloads.

Download Operations-Upgrade-9.1.1.0.25679887.pak. The portal also provides the checksums that we can use to validate the file after the download.

Checking the Cluster Before the Upgrade

Open the VCF Operations administration interface at https://<primary-node-fqdn>/admin and log in with the local admin account.

Go to System Status and make sure the cluster is Online and every node is Running. In my lab the starting node version was 9.1.0.0400.25541561.

Go to Software Update. The previously installed update in my lab was 9.1.0.0400.25541550. Click Install a Software Update.

Uploading the PAK File

Click Browse, select Operations-Upgrade-9.1.1.0.25679887.pak, and click Upload. Leave Install the PAK file even if it is already installed unchecked.

The upload can take some time because the PAK is just over 7 GB. Once it finishes, confirm that the signature is valid and that the version is 9.1.1.0.25679887, then click Next.

Review the End User License Agreement, select I accept the terms of this agreement, and click Next.

On the last page, click Install. The installer restarts the cluster before copying the files, and the administration interface will become unavailable for a while.

Monitoring the Upgrade

Once all 14 steps complete, the status changes to Applied and Cleaned. In my single-node lab the install took about 40 minutes after the PAK finished uploading.

Verifying the Upgrade

Go back to System Status and verify that the cluster is Online and every node is Running. The final node version in my lab is 9.1.1.0.25679751.

And with that we are finished upgrading the VCF Operations cluster to 9.1.1. If this is part of a full VCF 9.1.1 upgrade, don’t forget to continue with the remaining components in the order listed in the release notes.

Updating ESXi with the Authenticated Broadcom Depot or an Offline Bundle

Cosmin Trif — Tue, 25 Aug 2026 23:05:00 +0000

This is the corrected follow-up to my earlier ESXi command-line upgrade articles. The shared public VMware host-update depot used in those examples is no longer valid. Broadcom now uses customer-specific authenticated download URLs, and its current standalone command-line procedure documents an offline depot ZIP with esxcli software profile update.

The procedure and release information below were reviewed on August 25, 2026. Reopen the linked Broadcom articles during every change: depot authentication, entitlements, available profiles, release builds and support status can change.

Scope: This article is for a standalone, profile-based ESXi update when esxcli is an approved lifecycle method. For a VCF-managed host, use the supported VCF lifecycle workflow. For a cluster managed with a vSphere Lifecycle Manager desired image, remediate through vLCM so the host does not drift from that image. NSX-prepared hosts have additional sequencing and kernel-module requirements.

Do Not Select a Build Merely Because It Is Called Latest

An image-profile name is an exact change target, not a moving alias. Choose the release required by the approved bill of materials, upgrade path, hardware support and product interoperability. Then copy the exact profile name reported by the selected depot.

The three old examples were pinned to releases that Broadcom’s build-number table now shows as superseded:

Historical article target	What the current table shows
ESXi 7.0 Update 3f, build 20036589	Later ESXi 7 entries exist, through Update 3w, build 24784741. ESXi 7 reached End of General Support on October 2, 2025.
ESXi 8.0 Update 3b, build 24280767	Later releases exist in the 8.0 Update 3 train, including Update 3k, build 25595708.
ESX 9.0 GA, build 24755229	Later 9.0 releases and a separate 9.1 train exist. The table lists 9.0.2.0100 build 25595025 and 9.1.0.0200 build 25557999.

Those values describe the table on the review date; they are not recommendations and must not be copied as an automatic target. In particular, a numerically higher build in another maintenance or major-version train is not proof that it is the correct upgrade for an environment.

Confirm the Lifecycle Method and Exact Target

Before downloading or applying an image:

Confirm the supported upgrade path in the Broadcom Product Interoperability Matrix, including vCenter Server, NSX, vSAN and every integrated VMware product.
Verify the server model, CPU, boot device, NICs, storage controllers, drivers, firmware and BIOS in the Broadcom Compatibility Guide. Use the current vendor-customized image when the hardware vendor requires it.
Read the target release notes and identify whether the required artifact is under Products or Solutions in the Broadcom Support Portal. Broadcom explains that base releases and patch releases can appear in different areas.
For an NSX-prepared host, follow Broadcom KB 312013 for the matching NSX kernel-module bundle and upgrade sequence. Do not apply a generic image and assume the NSX packages will remain correct.
If the host is VCF-managed or governed by a vLCM desired image, stop using this standalone procedure and use that product’s lifecycle workflow.

ESXi 7 is now a legacy, end-of-general-support release. Do not treat a newer ESXi 7 patch as a substitute for an approved migration plan. Use post-EoGS content or a downgrade only under the applicable support policy and Broadcom Support guidance.

Prepare the Host

Before changing the host:

Take a current ESXi configuration backup and verify the recovery path.
Migrate or shut down all user VMs. Do not manually move or power off vCLS VMs unless Broadcom Support directs you to do so.
Confirm the remaining cluster can satisfy the intended vSphere HA failover policy while this host is unavailable.
For vSAN, confirm cluster health and object compliance, wait for active resynchronizations to finish, and select the maintenance-mode data-migration option appropriate to the storage policies and available capacity.
Keep out-of-band console access available and patch one host at a time unless the validated design explicitly permits parallel remediation.

Enter maintenance mode from the vSphere Client and confirm it from the ESXi shell:

vim-cmd hostsvc/hostsummary | grep inMaintenanceMode

Continue only when the result is true.

Preferred Method: Use an Offline Depot Bundle

Broadcom’s current standalone esxcli procedure uses an offline depot ZIP. Download the artifact for the exact approved release from the Broadcom Support Portal or the hardware vendor, then upload it to a datastore accessible by the host. Confirm the upload completed and retain the portal filename and release information with the change record.

Set the path to the uploaded file. Replace the uppercase example components with the actual datastore, directory and filename:

OFFLINE_BUNDLE='/vmfs/volumes/DATASTORE/updates/ESXI_DEPOT_BUNDLE.zip'

List every image profile in that bundle:

esxcli software sources profile list -d "$OFFLINE_BUNDLE"

Read the target release notes to distinguish standard, no-tools, security-only and vendor-customized profiles. Copy one exact profile name from the command output only after confirming it matches the approved target:

TARGET_PROFILE='COPY_EXACT_PROFILE_NAME_FROM_LIST_OUTPUT'

Inspect the current host profile and perform a dry run:

esxcli software profile get
esxcli software profile update --dry-run -d "$OFFLINE_BUNDLE" -p "$TARGET_PROFILE"

Treat every dependency, acceptance-level, hardware, space or package-removal message as a failed precheck until it is understood. A clean dry run is still not proof that the host will boot or rejoin the cluster successfully. Do not add --force, --no-sig-check, --ok-to-remove or compatibility-bypass flags to make the command pass.

Broadcom documents a false dry-run failure on ESXi 7 releases earlier than 7.0 Update 3i when a target profile contains the newer ESXio content. Do not simply ignore that failure. Move to the fixed baseline through an approved path, use the supported lifecycle workflow, or obtain Broadcom Support guidance for the exact source and target.

When the dry-run result and change target have been reviewed, apply the same profile without --dry-run:

esxcli software profile update -d "$OFFLINE_BUNDLE" -p "$TARGET_PROFILE"

profile update normally preserves vendor/OEM components unless they are superseded. Do not replace it with profile install unless the exact upgrade documentation or Broadcom Support requires installation semantics and the planned package removals have been reviewed. Starting with ESXi 8.0 Update 2, esxcli software vib update and esxcli software vib install are not supported for changing the ESXi version.

Alternative: Use the Authenticated Broadcom Online Depot

Use the online method only when direct host access to dl.broadcom.com is permitted and the change workflow accepts a customer-specific token in the depot URL. Broadcom says only a Product Administrator can generate a download token for an entitled Site ID. A newly generated token can also take a short time to become valid.

Treat the token like a credential: do not publish it, add it to source control, include it in screenshots, or paste it into tickets and chat transcripts. Prefer the offline-bundle method when shell history, process arguments or logs containing the authenticated URL would violate credential-handling policy.

Temporarily enable the outbound HTTP client ruleset:

esxcli network firewall ruleset set -e true -r httpClient

Set the authenticated main-depot URL, replacing REPLACE_WITH_DOWNLOAD_TOKEN with the token for the entitled Site ID:

DEPOT_URL='https://dl.broadcom.com/REPLACE_WITH_DOWNLOAD_TOKEN/PROD/COMP/ESX_HOST/main/vmw-depot-index.xml'

List the depot profiles and copy the exact approved profile name from the output:

esxcli software sources profile list -d "$DEPOT_URL"
TARGET_PROFILE='COPY_EXACT_PROFILE_NAME_FROM_LIST_OUTPUT'

Run only the precheck first:

esxcli software profile update --dry-run -d "$DEPOT_URL" -p "$TARGET_PROFILE"

When the dry run succeeds and its output has been reviewed, apply the update as a separate action:

esxcli software profile update -d "$DEPOT_URL" -p "$TARGET_PROFILE"

Disable the temporary firewall exception and remove the shell variables when the depot is no longer needed:

esxcli network firewall ruleset set -e false -r httpClient
unset TARGET_PROFILE DEPOT_URL

An HTTP 401 or 403 response can indicate a wrong Site ID, insufficient entitlement, a token that has not propagated yet or a token-access problem. Validate it with Broadcom’s authenticated-download troubleshooting guide instead of reverting to the retired public depot. Fix proxy and certificate trust problems; do not disable TLS certificate verification.

Reboot and Validate Before Exiting Maintenance Mode

If the profile update reports that a reboot is required, keep the host in maintenance mode and reboot it:

esxcli system shutdown reboot -r 'apply ESXi profile update'

After the host finishes booting, verify the version and active profile:

vmware -vl
esxcli software profile get

Before returning the host to service, also validate:

Management networking, physical NICs, DNS and host connectivity to vCenter Server.
Storage adapters, paths, datastores and expected multipathing policy.
vSphere HA, DRS and cluster alarms.
vSAN health, object compliance and any post-reboot resynchronization.
NSX transport-node, tunnel, datapath and kernel-module status when applicable.
Compliance with the intended vLCM image or VCF bill of materials.

Exit maintenance mode only after these checks succeed:

vim-cmd /hostsvc/maintenance_mode_exit

Disable SSH or ESXi Shell again if it was enabled only for this change.

Official References

Safely Removing an SDDC Manager-Deployed NSX Edge Cluster from VCF

Cosmin Trif — Tue, 25 Aug 2026 12:05:00 +0000

This is the corrected follow-up to my older article about simplifying NSX Edge removal in VCF. The most important correction is that the Edge Cluster Deployment Removal Tool does not preserve everything attached to an Edge cluster. Broadcom requires added dependencies to be removed or disconnected before the cleaner runs.

The procedure below is based on Broadcom KB 316110, reviewed on August 25, 2026. Always reopen the KB before a change because the attachment, checksum, prerequisites, and supported releases can change.

Destructive operation: The cleaner removes the selected deployment’s NSX gateways, Edge cluster and node VMs, network objects, associated vCenter objects, and SDDC Manager inventory records. A successful dry run is necessary, but it is not a rollback mechanism and does not replace dependency analysis or backups.

Confirm That the Deployment Is Supported

Use this cleaner only for an NSX Edge cluster deployment created through one of these SDDC Manager workflows:

An Application Virtual Network (AVN) bring-up workflow.
The SDDC Manager Edge Cluster Creation workflow, including the corresponding UI workflow.

KB 316110 describes the cleaner as intended for freshly deployed Edge clusters. Stop and open a Broadcom Support case when the deployment’s origin or current inventory association is unclear.

The current cleaner also exposes a separate --db-removal-only mode for a specific VCF 9.x imported-Edge inventory scenario. That mode does not perform the deployment cleanup described here and is outside this article’s scope; use it only under the current KB instructions or Broadcom Support guidance.

Do not use this workflow when:

The Edge cluster is being used by Workload Control Plane (WCP), vSphere with Tanzu, or dependent Kubernetes services.
The Edge cluster was created outside the supported SDDC Manager workflows.
Edge VMs, gateways, or inventory records were already deleted manually and SDDC Manager no longer matches NSX or vCenter.
Fabric or logical objects created by SDDC Manager were renamed and their original names are unknown.
The requested action is to shrink, migrate, or repair an active Edge cluster rather than remove the deployment.

Manual deletion can leave SDDC Manager inventory out of sync with NSX and vCenter. Broadcom directs administrators who reach that state to open a support case rather than continue deleting objects; see KB 437372.

Remove Dependencies Before Running the Cleaner

Inventory everything using the Edge cluster and migrate or remove it before continuing. This includes, as applicable:

Added Tier-0 or Tier-1 gateway configuration.
Segments linked to a Tier-1 gateway.
Interfaces, services, static routes, NAT, VPN, load-balancing, DHCP, or other configuration attached above the SDDC Manager-created deployment.
External Connections and Transit Gateway dependencies in applicable VCF 9.x deployments.
WCP and related components, which must be removed through the supported vCenter workflow before the Edge cluster can be reconsidered for cleanup.

Revert renamed fabric or logical entities to the names assigned by the SDDC Manager deployment workflow. The cleaner has only limited ability to disconnect linked segments; do not rely on the dry run to discover or safely migrate every application dependency.

Obtain approval from the network and application owners after confirming that removing the identified gateways and Edge nodes will not interrupt a service that should remain available.

Prepare Backups and Recovery Access

Before running a destructive cleanup:

Verify a current, successful NSX file-based backup and confirm access to its passphrase and remote backup files.
Follow the current VCF backup guidance for SDDC Manager. Take an SDDC Manager VM snapshot only when the Broadcom procedure or Support guidance for the specific scenario instructs you to do so, and remove it promptly after successful validation.
Do not snapshot NSX Manager, Global Manager, or Edge appliances. Broadcom documents that VM snapshots of NSX appliances are unsupported and can cause database corruption or cluster instability; use the supported NSX file-based backup instead. See KB 433822.
Schedule a maintenance window and keep console access to SDDC Manager, NSX, and vCenter available.

Download and Verify the Current Tool

Open KB 316110 and download its current Edge cleaner attachment. Do not reuse an older tarball or a bookmarked attachment URL.

The KB publishes the filename and hashes for its current attachment and warns that the hashes change when the file changes. Copy the tarball to /home/vcf on the SDDC Manager appliance, not /tmp, then calculate its SHA-256 hash:

cd /home/vcf
sha256sum 'edge_cluster_cleaner_<version>.tar.gz'

Replace <version> with the exact version in the downloaded filename. Compare the entire result with the current SHA-256 value shown in KB 316110. Stop if the filename or hash does not match.

Extract the verified attachment and inspect the bundled help:

tar -xzvf 'edge_cluster_cleaner_<version>.tar.gz'
cd cleanup
./remove_edge_cluster.sh --help

Use the flags reported by the downloaded tool. If its syntax differs from the KB or this article, stop and reconcile the version before continuing.

Run a Dry Run First

Use the exact Edge cluster name and, when supplied, the exact workload-domain name. Use a vCenter SSO administrator for the workload domain. Do not place its password on the command line; when neither a password flag nor password environment variable is supplied, the tool prompts for it without storing it in shell history.

./remove_edge_cluster.sh \
 --cluster '<EDGE_CLUSTER_NAME>' \
 --workload '<WORKLOAD_DOMAIN_NAME>' \
 --user '<SSO_ADMIN_USER>' \
 --dryrun \
 --verbose

The --workload argument is optional in the documented tool, but specifying the intended domain makes the target explicit. Review the dry-run output and generated log from beginning to end. Confirm that:

The tool authenticated to the intended environment.
The selected Edge cluster and workload domain are correct.
Every object proposed for deletion belongs to the intended deployment.
No unexpected dependency, renamed object, validation failure, or inventory mismatch appears.

If any check fails, do not add force or warning-suppression flags. Correct the prerequisite or open a Broadcom Support case, then repeat the dry run.

Run the Live Cleanup

After the dry run succeeds and the change is approved, run the same command without --dryrun:

./remove_edge_cluster.sh \
 --cluster '<EDGE_CLUSTER_NAME>' \
 --workload '<WORKLOAD_DOMAIN_NAME>' \
 --user '<SSO_ADMIN_USER>' \
 --verbose

Read the warning and confirm the target interactively. Do not use --skip-warning merely to make the example noninteractive. Keep the terminal connected until the cleaner finishes and retain its log with the change record.

KB 316110 notes that a transient timeout can occasionally stop cleanup partway through. In that documented timeout condition, inspect the log and rerun the same cleaner invocation. If the Edge cluster was dissolved but its Edge node VMs remain, follow the KB’s specific direction to remove those residual Edge Transport Node VMs through the NSX UI. Do not improvise manual deletion for other partial states.

Validate All Three Inventories

After the cleaner reports success, verify the result in:

SDDC Manager: the Edge deployment and its workload-domain inventory association are removed.
NSX Manager: the intended gateways, Edge cluster, Edge nodes, uplink segments, and SDDC Manager-created transport-zone objects are gone, with no new alarms or stale dependencies.
vCenter Server: the intended Edge node VMs, port groups, and deployment resource pool are gone, while unrelated infrastructure remains present.

Also test the management and workload paths that were intentionally migrated away from the removed Edge cluster. If the three inventories disagree, stop. Do not manually delete more objects to make the screens match; collect the cleaner log and support bundles and open a Broadcom Support case.

What the Cleaner Normally Removes

Depending on whether the deployment came from AVN bring-up or direct SDDC Manager Edge creation, KB 316110 says the cleaner normally removes some or all of the following:

The deployment’s Tier-0 and Tier-1 gateways.
The Edge cluster and Edge node VMs.
Edge uplink segments and deployment-created VLAN transport zones.
Deployment-created vCenter port groups and resource pool.
The corresponding SDDC Manager inventory records.

That list is the reason dependency removal and a reviewed dry run come first. The cleaner is a deployment-removal tool, not an application-migration or dependency-preservation tool.

Official References

VMSA-2025-0004: Current Remediation and Fixed Versions

Cosmin Trif — Tue, 25 Aug 2026 12:00:00 +0000

Broadcom published VMSA-2025-0004 on March 4, 2025, for three vulnerabilities affecting VMware ESXi and related desktop and cloud products. Fixed versions are available, and the advisory lists no workarounds for any of the three vulnerabilities.

The practical response is therefore straightforward: identify every affected product, move it to a fixed or later supported build using its supported update method, and verify the resulting build. Access restrictions and monitoring remain useful defense-in-depth controls, but they do not replace the update.

Fixed Versions

The following table reflects Broadcom’s VMSA response matrix. Where a newer supported update is available and compatible with your environment, use that newer update rather than treating the minimum fixed build as a preferred long-term target.

Product	Affected branch	Minimum remediation listed by Broadcom
VMware ESXi	8.0	`ESXi80U3d-24585383` or `ESXi80U2d-24585300`, depending on the maintained branch
VMware ESXi	7.0 (EOGS)	`ESXi70U3s-24585291`
VMware Workstation	17.x	17.6.3
VMware Fusion	13.x	13.6.3
VMware Cloud Foundation	5.x	Async patch to `ESXi80U3d-24585383`
VMware Cloud Foundation	4.5.x (EOGS)	Async patch to `ESXi70U3s-24585291`
VMware Telco Cloud Platform	5.x, 4.x, 3.x, 2.x	Follow Broadcom KB 389385
VMware Telco Cloud Infrastructure	3.x, 2.x	Follow Broadcom KB 389385

The ESXi 7.0 and VCF 4.5.x entries record the advisory’s March 2025 minimum fixes; they are not current supported target releases. vSphere 7.0 reached End of General Support on October 2, 2025, and Broadcom’s current VCF release matrix places VCF 4.x under End of General Support. Unless a specific Extended Support agreement or Broadcom Support direction applies, plan migration to a supported release rather than stopping at those legacy builds.

Cloud Foundation administrators should use the VCF async-patching procedure linked from the advisory rather than independently applying an ESXi image that has not been accounted for in the VCF bill of materials. Also confirm hardware, firmware, driver, add-on, backup, replication, and management-product interoperability before beginning a production rollout.

The advisory is the source of truth if its matrix changes after this article is published.

Understand the Three Vulnerabilities Correctly

These vulnerabilities are related, but they do not all provide the same capability:

CVE-2025-22224 — VMCI heap overflow: A malicious actor with local administrative privileges inside a VM may execute code as that VM’s VMX process on the host. Broadcom rates it Critical with a maximum CVSSv3 score of 9.3.
CVE-2025-22225 — ESXi arbitrary write: An actor who already has privileges within the VMX process may trigger an arbitrary kernel write and escape the VMX sandbox. Broadcom rates it Important with a maximum CVSSv3 score of 8.2.
CVE-2025-22226 — HGFS information disclosure: An actor with administrative privileges inside a VM may exploit an out-of-bounds read to disclose memory from the VMX process. Broadcom rates it Important with a maximum CVSSv3 score of 7.1.

This distinction matters. CVE-2025-22224 provides code execution in the VMX process; it should not be described by itself as complete host takeover. CVE-2025-22225 is the sandbox-escape step described by the advisory. CVE-2025-22226 is an information-disclosure issue, not a code-execution issue.

Broadcom’s current advisory states that it has information suggesting exploitation of all three CVEs has occurred in the wild.

Recommended Remediation Workflow

Inventory the affected products and exact builds. Include standalone ESXi, VCF-managed hosts, Workstation, Fusion, and applicable Telco products.
Compare each build with the current advisory. Do not rely only on a scanner’s advisory title; confirm the installed build against the response matrix.
Plan the supported update path. Check compatibility and product-specific prerequisites. For VCF, use the documented async-patching workflow referenced by Broadcom.
Protect recoverability. Confirm that current configuration backups and workload recovery plans are usable before changing production infrastructure.
Evacuate and maintain hosts correctly. For clustered ESXi hosts, migrate or shut down workloads as appropriate and place each host into maintenance mode before applying its supported lifecycle operation.
Apply the fixed or a later supported build. There is no Broadcom workaround that substitutes for this step.
Verify the result. Confirm the reported build, cluster health, management connectivity, storage and network health, and workload availability before returning the host to service.
Continue monitoring. Review security telemetry and incident-response data for activity that predates remediation; applying the fixes blocks these vulnerable code paths but does not prove that earlier exploitation did not occur.

No Workaround Means No Equivalent Configuration Fix

Broadcom lists None in the Workarounds column for CVE-2025-22224, CVE-2025-22225, and CVE-2025-22226. Restricting administrative access inside VMs, segmenting management networks, and monitoring hosts are sensible controls, but they do not remove the vulnerable code and should not be presented as equivalent remediation.

Historical Context

My original March 2025 article described the initial urgency correctly but incorrectly stated that patches were not yet available. Broadcom’s initial advisory already included fixed versions. I have corrected the original article and retained it as historical context, while this page provides the current remediation-first guidance.

Official References

Safely Removing Stale NSX VIBs from an ESXi Host

Cosmin Trif — Tue, 25 Aug 2026 09:00:00 +0000

This post replaces the unsafe package-removal command that appeared in my older article about removing stale NSX packages from an ESXi host. Broadcom now documents a clear distinction between removing NSX through its management workflow and cleaning up VIBs that remain afterward.

Warning: Do not manually remove individual NSX VIBs with esxcli software vib remove. Broadcom identifies that method as unsupported. It can break distributed-switch state, disconnect host networking, and in some failure cases leave reimaging as the recovery path.

When This Procedure Applies

Use this workflow for the documented stale-package condition: NSX has already been removed from the host through NSX Manager, or the host has been removed from NSX Manager, but NSX VIBs remain on ESXi. One example is the dependency error covered by Broadcom KB 409544, where vsipfwlib remains dependent on nsx-proto2-libs.

This is not a shortcut for dismantling an active transport node. If NSX Manager still shows the host as configured, if workloads or VMkernel adapters still depend on NSX-backed networking, or if the supported removal command reports attached resources, resolve those dependencies before continuing. Do not bypass the command’s safety checks by deleting individual VIBs.

Step 1: Evacuate the Host and Enter Maintenance Mode

Before attempting either the NSX Manager removal or the stale-VIB cleanup:

Evacuate powered-on workloads from the host.
Put the host into maintenance mode.
Confirm that the cluster and its storage can tolerate the host being unavailable.
Keep console or out-of-band management access available in case normal host networking is interrupted.

Do not perform this cleanup on an in-service host.

Step 2: Remove or Unprepare the Host in NSX Manager

Use NSX Manager as the first removal method. Select the applicable Remove NSX or unprepare action for the host transport node. The exact navigation label varies by NSX release. Wait for NSX Manager to report the host as Not Configured before treating the remaining packages as stale.

For one currently documented reinstall scenario, Broadcom directs administrators to go to System > Fabric > Hosts, move the host out of the prepared cluster, and use Remove NSX if it does not transition to Not Configured. See KB 401684 and confirm the matching procedure for your installed NSX version.

Step 3: Confirm Which NSX VIBs Remain

esxcli software vib list | grep -E 'nsx|vsipfwlib'

Record the output for troubleshooting. If the command returns no matching packages, there are no NSX VIBs for this procedure to remove. Reconcile the host’s state in NSX Manager instead of continuing blindly.

Step 4: Use the Supported NSX Removal Command

For the stale-VIB condition documented in KB 409544, run:

nsxcli -c del nsx

Allow the command to complete. If it fails, stop and address the reported dependency or attached-resource condition. Do not replace it with individual esxcli software vib remove commands. Broadcom’s KB 426464 explicitly says to correct the condition causing del nsx to fail rather than using the unsupported ESXCLI method.

Step 5: Reboot and Verify the Host

KB 409544 requires a reboot after the removal. Reboot the host while it remains in maintenance mode. After it has returned, log in and repeat the package check:

esxcli software vib list | grep -E 'nsx|vsipfwlib'

For the KB 409544 condition, the expected result is no matching NSX VIBs. Also verify that:

The management interface is reachable.
NSX Manager reports the host as Not Configured if it is meant to remain unprepared.
No stale NSX-backed distributed-switch resources remain associated with the host.

If you intend to prepare the host again, initiate that operation from NSX Manager. Wait for the transport node to report a healthy state, then validate management connectivity, workload networking, and tunnel status before exiting maintenance mode.

If ESXCLI Removal Was Already Attempted

If individual NSX VIBs were already removed and the host lost network connectivity, do not continue removing packages. Use console or out-of-band access and follow the recovery article that matches the symptom:

KB 426464: ESX host loses network connectivity after running ESXCLI removal on NSX VIBs warns that affected hosts can require reimaging.
KB 394809: NSX VIBs were uninstalled using ESXCLI, causing network outages documents a console-based recovery path and highly recommends reimaging afterward to avoid unexpected effects.

When the host’s current state does not match either documented scenario, collect diagnostics and open a Broadcom Support case rather than combining cleanup commands from unrelated KB articles.

Official References

Safely Canceling and Deleting Alerts with the VCF Operations API

Cosmin Trif — Tue, 25 Aug 2026 00:00:00 +0000

The VCF Operations API uses different payloads for finding, canceling, and deleting alerts. Treating those operations as interchangeable can either fail validation or broaden a cleanup beyond the alerts you intended to remove.

This follow-up corrects the API section in Bulk Delete Alerts in VCF Operations. The safe sequence is:

Query candidate alerts without changing them.
Review every returned alert ID and account for pagination.
Cancel only the approved IDs with a uuid-values body.
Verify those IDs are now CANCELED.
Delete the same IDs with a direct AlertQuery body.
Query again to confirm that they are gone.

Before You Begin

Fix or tune the alert definition first. Deleting alert history does not stop the condition from generating new alerts.
Use a VCF Operations account whose application role and object scope permit the required alert operations.
Take any database backup required by your change policy before a large cleanup.
Start with one small batch. The API documents a default query page size of 1,000, so a single response is not proof that you found every match.
Use a trusted certificate. The examples intentionally do not bypass TLS verification.

Set the appliance name, create a private working directory, and read an existing session token without placing it in shell history. Store the authorization header in a mode-600 file so the token is not expanded into each curl process argument, then remove it as soon as the cleanup is verified:

export OPS_FQDN='ops.example.com'
umask 077
OPS_WORK_DIR="$(mktemp -d /tmp/vcf-ops-alert-cleanup.XXXXXX)"
read -r -s -p 'VCF Operations token: ' OPS_TOKEN
printf '\n'
printf 'Authorization: OpsToken %s\n' "$OPS_TOKEN" \
 > "${OPS_WORK_DIR}/authorization.header"
chmod 600 "${OPS_WORK_DIR}/authorization.header"
unset OPS_TOKEN

Current VCF Operations API requests use this header:

Authorization: OpsToken TOKEN_VALUE

You can obtain the session token from POST /suite-api/api/auth/token/acquire. Do not save the token, account password, or response in a shared script or repository.

Step 1: Query a Narrow Candidate Set

Use POST /suite-api/api/alerts/query with an AlertQuery. Prefer an exact alertDefinitionId, resource ID, or an already reviewed list of alert IDs. The alertName field uses contains logic and is therefore less precise.

Create a query for one exact alert definition:

{
 "compositeOperator": "AND",
 "activeOnly": true,
 "alertDefinitionId": [
 "11111111-2222-3333-4444-555555555555"
 ]
}

Save that JSON as ${OPS_WORK_DIR}/alert-candidates.json, replace the example UUID, and query the first page:

curl --fail-with-body \
 --request POST \
 "https://${OPS_FQDN}/suite-api/api/alerts/query?page=0&pageSize=1000" \
 --header @"${OPS_WORK_DIR}/authorization.header" \
 --header 'Content-Type: application/json' \
 --data-binary @"${OPS_WORK_DIR}/alert-candidates.json" \
 --output "${OPS_WORK_DIR}/alert-page-0.json"

Review the count and identifying fields before doing anything destructive:

jq '.pageInfo, [.alerts[] | {alertId, alertDefinitionId, alertDefinitionName, resourceId, status}]' \
 "${OPS_WORK_DIR}/alert-page-0.json"

If pageInfo.totalCount exceeds the number returned, query every remaining page and review it. Keep batches small enough to audit. Never replace the query with {} merely to avoid pagination.

Step 2: Build and Review the Exact Cancel List

The modify-alerts endpoint does not accept an AlertQuery. It requires a uuid-values body whose only required field is the uuids array.

After reviewing the first batch, build the body from its returned IDs:

jq '{uuids: [.alerts[].alertId]}' \
 "${OPS_WORK_DIR}/alert-page-0.json" \
 > "${OPS_WORK_DIR}/alerts-to-cancel.json"

jq . "${OPS_WORK_DIR}/alerts-to-cancel.json"

Record the approved count and retain the reviewed ID list with the change record.

Step 3: Cancel Only Those IDs

Cancel the exact list with POST /suite-api/api/alerts?action=cancel:

curl --fail-with-body \
 --request POST \
 "https://${OPS_FQDN}/suite-api/api/alerts?action=cancel" \
 --header @"${OPS_WORK_DIR}/authorization.header" \
 --header 'Content-Type: application/json' \
 --data-binary @"${OPS_WORK_DIR}/alerts-to-cancel.json" \
 --output "${OPS_WORK_DIR}/alert-cancel-response.json"

jq '[.alerts[] | {alertId, status, cancelTimeUTC}]' \
 "${OPS_WORK_DIR}/alert-cancel-response.json"

Canceling changes alert state; it does not delete the alert record.

Step 4: Build the Targeted Delete Query

The delete endpoint accepts a direct AlertQuery, not an alert-query wrapper. Reuse the reviewed IDs and require CANCELED status:

jq '{
 compositeOperator: "AND",
 alertStatus: ["CANCELED"],
 alertId: .uuids
 }' \
 "${OPS_WORK_DIR}/alerts-to-cancel.json" \
 > "${OPS_WORK_DIR}/alerts-to-delete.json"

jq . "${OPS_WORK_DIR}/alerts-to-delete.json"

Run the same body through the read-only query endpoint first:

curl --fail-with-body \
 --request POST \
 "https://${OPS_FQDN}/suite-api/api/alerts/query?page=0&pageSize=1000" \
 --header @"${OPS_WORK_DIR}/authorization.header" \
 --header 'Content-Type: application/json' \
 --data-binary @"${OPS_WORK_DIR}/alerts-to-delete.json" \
 --output "${OPS_WORK_DIR}/alert-delete-preview.json"

jq '.pageInfo, [.alerts[] | {alertId, alertDefinitionName, resourceId, status}]' \
 "${OPS_WORK_DIR}/alert-delete-preview.json"

Stop if the preview contains an unexpected ID, definition, resource, or status. The preview count should match the reviewed cancel list for that batch.

Step 5: Delete and Verify

Delete the targeted canceled alerts with DELETE /suite-api/api/alerts/bulk:

curl --fail-with-body \
 --request DELETE \
 "https://${OPS_FQDN}/suite-api/api/alerts/bulk" \
 --header @"${OPS_WORK_DIR}/authorization.header" \
 --header 'Content-Type: application/json' \
 --data-binary @"${OPS_WORK_DIR}/alerts-to-delete.json"

The documented success response is HTTP 204 and indicates that the deletion was started. It does not return a deleted-object list. Query the exact IDs again until the API returns no matching alerts, and confirm the expected result in the UI and audit history before closing the change.

Delete the temporary authorization header immediately. Retain or securely remove the reviewed JSON files according to the change-record policy, then remove the directory when it is empty:

rm -f -- "${OPS_WORK_DIR}/authorization.header"
unset OPS_TOKEN
# After retaining or deleting the reviewed JSON files:
rmdir -- "$OPS_WORK_DIR"
unset OPS_WORK_DIR

Requests to Avoid

Do not send an empty {} query to the bulk-delete endpoint.
Do not use only alertStatus: ["CANCELED"] unless the approved scope is explicitly every canceled alert in the environment.
Do not put an AlertQuery inside an alert-query wrapper; the endpoint expects the query fields at the JSON root.
Do not send alert IDs directly to DELETE /suite-api/api/alerts; the documented bulk deletion route is /suite-api/api/alerts/bulk.
Do not assume the first 1,000 results are the complete set.
Do not schedule destructive cleanup until the query, count limits, audit logging, and failure handling have been tested with a small batch.

References

Using a 90-Day Planning Horizon Correctly in VCF Operations

Cosmin Trif — Tue, 25 Aug 2026 00:00:00 +0000

A 90-day capacity goal can describe three different things in VCF Operations: past demand used by the projection, future warning lead time, or the future period considered by VM rightsizing. They are controlled separately.

This article replaces the earlier 90-day capacity procedure, which incorrectly treated Time Remaining thresholds as a historical lookback setting.

The Three Meanings of 90 Days

Planning question	Relevant control	What it does not control
Should the forecast consider up to 90 days of past demand?	Historical Data window, if that value is available in the installed build	Alert severity or procurement lead time
Should an alert become critical when exhaustion is projected within 90 days?	Time Remaining criticality thresholds	Historical lookback
Should Recommended Size cover demand projected across a 90-day future horizon?	The applicable Time Remaining warning/green threshold plus the documented 30-day extension	Past-data retention

Changing one row does not configure the other two.

What the Capacity Engine Actually Does

VCF Operations forecasts demand rather than simply averaging a fixed block of historical utilization. Current Broadcom guidance describes these behaviors:

Recent samples receive more weight through exponential decay.
Conservative risk uses the upper bound of the projection range.
Aggressive risk uses the mean of the upper and lower projection bounds.
Peak-focused mode incorporates peaks detected in historical demand and can be combined with either risk posture.
Business Hours limits the demand samples used for projection to the configured hours; it does not merely give those hours extra weight.
Capacity Remaining is based on a short forward projection, while Time Remaining estimates when demand will intersect usable capacity.
vSphere HA admission-control reservations reduce usable cluster capacity and can therefore change the result even when current utilization appears low.

These settings change the model’s behavior. None of them, by itself, means “use exactly 90 days of history.”

Before Changing a Policy

Identify the active policy on the exact cluster, VM group, or object you are evaluating.
Record the existing Capacity settings and take screenshots for the change record.
Confirm whether the object is using the Demand model, the optional Allocation model, or both. Do not add arbitrary allocation ratios to hide a Demand-based alert.
Check vSphere HA admission control before interpreting usable capacity as missing physical capacity.
Decide which 90-day outcome you actually need: historical evidence, alert lead time, VM sizing horizon, or a documented combination.

Clone an inherited policy when you need a separate production, non-production, cluster, or VM posture. Broadcom recommends separate VM policies when rightsizing settings should differ from higher-level capacity policies.

Goal 1: Use a 90-Day Future Alert Lead Time

If procurement must begin when capacity is projected to run out within a quarter, configure Time Remaining severity thresholds for that operational lead time.

For example, an organization might choose warning at 120 days and critical at 90 days so the earlier warning leaves a 30-day intake buffer. Those numbers are governance choices, not Broadcom defaults. Keep the thresholds in a logical order, document who owns each severity, and verify how the installed version labels warning, immediate, and critical.

This configuration means “alert us based on a future exhaustion date.” It does not mean the forecast reads only the last 90 days.

Goal 2: Use a 90-Day VM Recommended Size Horizon

Broadcom’s current rightsizing explanation states that Recommended Size considers the peak projected demand from now through 30 days beyond the Time Remaining threshold used by the policy. Its example uses a 30-day warning threshold and therefore produces a 60-day sizing horizon.

Under that documented rule, a 90-day Recommended Size horizon corresponds to a 60-day applicable threshold plus the 30-day extension:

60-day policy threshold + 30-day extension = 90-day sizing horizon

Do not set the threshold to 90 days and call the sizing horizon 90 days; that would extend the evaluated period to 120 days under the same rule. Because UI wording can differ by release, verify the resulting projection on a VM’s Capacity tab before applying the policy broadly.

Use a VM-specific policy if clusters need different Time Remaining severities. Select Conservative, Aggressive, and Peak Focused according to workload risk and peak behavior, not merely to force a preferred recommendation.

Goal 3: Consider 90 Days of Historical Demand

The Historical Data setting is the control associated with the model’s past-data window. Broadcom KB 437777 explicitly treats it separately from Time Remaining risk and gives an example of temporarily reducing a 30-day window to one day when an obsolete spike is distorting a forecast.

To request a 90-day historical window:

Go to Infrastructure Operations > Configurations > Policy Definition.
Edit or clone the policy that is active on the intended objects.
Open Capacity and unlock the inherited Historical Data setting if necessary.
Select 90 days only if the installed VCF Operations build exposes 90 days as a supported value.
Save the policy, confirm its object assignment and precedence, and record the effective value.

If the installed build does not offer a 90-day value, do not substitute a 90-day Time Remaining threshold and describe it as a lookback. Use 90-day historical charts or reports as supporting evidence, and confirm the supported forecasting-window choices for that release with Broadcom Support.

Historical-data retention is also separate. Retaining a metric for reporting does not guarantee that every retained sample is used by the current projection.

Correcting Anomalous History

Use the Capacity view’s Reset control when a known change or anomaly makes the current projection unrepresentative. Broadcom documents two relevant behaviors:

Selecting a new projection start date causes forecasting to use data from that point forward.
Selecting a start and end time for exclusion omits that interval from capacity planning and forecasting.

A reset does not delete the underlying historical metric data. Charts, reports, and retained time-series data remain available.

Do not assume an object maintenance schedule is a substitute for this exclusion workflow. Maintenance behavior is designed around monitoring and alert handling; use the capacity engine’s own reset or exclusion controls when the goal is to change forecasting input.

Recalculate and Validate

Capacity forecasting runs periodically, so a policy change may not appear after one five-minute collection cycle. Broadcom KB 437777 describes two supported validation paths:

For a global recalculation, go to Administration > Control Panel > Dynamic Thresholds and start recalculation during an approved window.
For a specific cluster, open its Capacity tab and use Reset only when changing the projection baseline is intended.

Then validate all of the following:

The expected policy is active on the target object.
The effective Historical Data value matches the approved setting.
Time Remaining severity changes at the intended future thresholds.
The Capacity chart shows the expected projection start point and any excluded interval.
VM Recommended Size uses the intended future horizon.
HA reservation and capacity buffers match the actual resilience design.
Demand and Allocation models are interpreted separately, with the more constrained model understood.

Test on a small object group before broad assignment. Keep the before-and-after values with the change record so a surprising forecast can be traced to a specific policy decision.

References

Deploying a VCF 9.1 Fleet with the VCF Installer

Cosmin Trif — Fri, 07 Aug 2026 09:00:00 +0000

Last year, when VCF 9.0 shipped, I covered the VCF Installer in three posts: deploying the appliance, configuring it, and deploying a VCF 9 instance. With VCF 9.1 generally available since May 12, 2026, it was time to run the whole flow again in the lab, and enough has changed that it earns a fresh walkthrough. This post covers the complete path in one go: downloading and deploying the 9.1 installer appliance, connecting the depot, downloading binaries, and deploying a new VCF fleet on top of an existing vCenter. I used the 9.1.0.0400 installer from the July 2026 refresh.

What changed since the 9.0 posts

The overall shape is the same (deploy the OVA, connect a depot, download binaries, run the deployment wizard) but 9.1 moves a few important pieces, per the official What’s New for the VCF Installer and the depot KBs:

The download token is gone. Depot authentication now uses a Download Service ID + Activation Code obtained from the VCF Business Services console. The token flow from my 9.0 configuration post no longer applies. See KB 443647.
VCF Management Services are deployed by default. The installer now provisions the VCF services runtime, fleet lifecycle, identity broker, software depot, Salt RaaS, telemetry, and the centralized License Server as part of a new deployment.
Integrated planning workflow. The wizard generates CPU, memory, storage, VLAN, and FQDN requirements up front and validates your infrastructure against them, including a Pre-fill generated FQDNs button.
Auto-generated passwords. The installer can generate the component passwords for you, retrievable after deployment.
Dual-stack support. The appliance OVA now asks for an IP Address Version (IPv4 only, or IPv4 and IPv6), and existing dual-stack environments are supported, though wizard-driven deployments on an existing vCenter remain IPv4-only; dual-stack goes through a JSON spec.
Lowercase FQDNs are now formalized. The 9.1 planning docs state do not use capital letters in the FQDN, and uppercase component FQDNs are a documented deployment-failure known issue.

Download the VCF Installer

The appliance OVA comes from the Broadcom Support Portal at support.broadcom.com: select the VMware Cloud Foundations division, go to My Downloads, and pick VMware Cloud Foundation 9 with your target release. If the portal navigation fights you, KB 401497 walks through it.

Select the release. I grabbed 9.1.0.0400 from the July 2026 patch wave
Agree to the Terms and Conditions
Download VCF-SDDC-Manager-Appliance-9.1.0.0400.25570100.ova (2.28 GB) and verify the checksum

Deploy the VCF Installer appliance

Sizing is unchanged from 9.0: 4 vCPUs, 16 GB RAM, and 914 GB storage (thin provisioning keeps that honest), per the official deployment page. The docs describe two placement options: on one of the ESX hosts that will form the management domain (the appliance is converted into SDDC Manager during deployment), or outside the management infrastructure entirely, where one appliance can deploy multiple platforms. As in the 9.0 post, I am deploying the OVA through an existing vCenter.

Log in to vCenter with a user that can deploy an OVF
Right click the cluster and click Deploy OVF Template

Select Local file and upload the installer OVA
Click Next

Give the appliance a name
Select a deployment location
Click Next

Select a compute resource and wait for the compatibility checks
Click Next

Review the deployment details, note the 914 GB thick footprint vs 4.2 GB thin
Click Next

Read and accept the license agreements
Click Next

Select a datastore for the deployment
Click Next

Select the destination network: the appliance needs to reach the ESX hosts, the VM management network, DNS, and NTP
Click Next

Fill in the template customization: root and local user passwords (minimum 15 characters with the usual complexity rules; the local password is what you will use for admin@local in the UI and vcf over SSH), hostname, networking, DNS, and NTP
Click Next

This is also where 9.1 differs from 9.0: the networking section now starts with an IP Address Version selector, with IPv6 address, prefix length, and gateway fields if you go dual-stack.

Review the summary
Click Finish and wait for the deployment to complete

Log in and connect the depot

Once the appliance is up, navigate to https://ip_address/ui or https://hostname/ui. Same as 9.0, the services take a few minutes to start after first boot.

For username use admin@local
Enter the local user password from the OVA deployment
Click Log in

The Get Started page opens with the Download Binaries card flagging No Depot Connection.

Click Depot Settings and Binary Management

Both depot types are available: online (direct or via proxy) and offline, fed by the VCF Download Tool, only one can be connected at a time. For air-gapped environments the official offline depot procedure covers the Download Tool flow; William Lam also documented the new HTTP offline depot support in 9.1.

Click Configure under the Online Depot tile

Here is the big change from 9.0: instead of pasting a download token, the dialog shows the appliance’s Download Service ID (the docs and KB call it the Software Depot ID). Take that ID to the BSC portal at vcf.broadcom.com, register it, and you get an Activation Code back; the full flow is in the official depot procedure and KB 443647. The download token from KB 390098 that we used in the 9.0 post is not used here anymore.

Copy the Download Service ID and register it in the BSC portal to obtain the Activation Code
Enter the Activation Code (enable the proxy toggle if you need one)
Click Authenticate

Download the binaries

With the depot connected, the Binary Management section lists everything available for the release.

Confirm the Online Depot tile shows Depot connection active
In Binary Management, select the product and version, VMware Cloud Foundation 9.1.0.0 in my case
Select the binaries and click Download

The component list is a good illustration of how 9.1 patch waves work: the installer pulls the latest patch of each component rather than a single uniform build: SDDC Manager 9.1.0.0400, NSX 9.1.0.0200, VCF Automation 9.1.0.0200, VCF Operations 9.1.0.0400, and so on. William Lam has a good write-up of this default behavior if you need to pin earlier versions. Also note the sizes, VCF services runtime alone is 17.42 GB and VCF Automation 14.95 GB, so give the downloads some time.

Start the Deployment Wizard

Click Return Home: the Deploy card sits next to Download Binaries. Progress in the wizard is saved locally in the browser after each step, so you can safely step away

Click Deployment Wizard and select VMware Cloud Foundation

The dropdown also offers VMware vSphere Foundation: the 9.1 installer deploys VVF through the same wizard framework, with a reduced flow (no NSX Manager or SDDC Manager steps). That is a post for another day; everything below follows the VCF path.

Deploy VMware Cloud Foundation

The wizard runs through four phases: Introduction, Plan, Prepare, Deploy; the official procedure is Start a New VCF Fleet or a New VCF Instance Deployment.

Introduction

The About page is worth an actual read: it diagrams the VCF fleet concept and calls out that VCF 9.1 introduces VCF management services inside the management domain, next to vCenter, NSX Manager, and SDDC Manager. The installer deploys the management domain; workload domains come later from VCF Operations.

Three deployment paths are offered: a new VCF fleet, a new VCF instance joining an existing fleet’s VCF Operations, or deploying deferred components. Same as in my 9.0 fleet post, this lab is a fresh start.

Select Deploy a new VCF fleet
Click Next

Plan

Check I have an existing vCenter instance: the wizard will collect and validate the details later
Click Next

You can also flag an existing VCF Operations 9.1 instance or an NSX-registered vCenter here. VCF Automation is no longer a hard requirement at deployment time; it can be connected or deployed later as a day-N operation.

Select the Deployment model. I went with Simple, which locks the size to Small
Review the component sizing table and click Next

The sizing table is part of the new integrated planning workflow, and it is worth pausing on: VCF management services alone ask for 40 vCPUs, 82 GB RAM, and 3 TB of disk in this smallest configuration.

Review the Network Options: by default VCF Operations, VCF Automation, and the management services land on the VM management network, and a distributed Transit Gateway is configured to make the domain VPC-ready
Click Next (or Customize if you need separate networks)

One caveat straight from the wizard: with an existing vCenter the wizard supports IPv4-only; dual-stack deployments have to go through a JSON spec.

The Review Prerequisites step is the payoff of the planning workflow: capacity totals (2 hosts, 84 vCPUs, 254 GB RAM, 5,244 GB disk for my configuration), VLAN requirements (none for this path), and the exact FQDN and IP requirements: 12 IPs for the management services pool, 5 for VCF Automation, plus FQDNs for Cloud proxy, NSX Manager, VCF Operations, and the License Server. The Pre-fill generated FQDNs in wizard button carries these into the later steps. Remember: lowercase only, forward and reverse resolvable.

Create the DNS records and reserve the IP ranges
Click Next

Prepare

Select the Version: 9.1.0.0, with the latest downloaded patch of each component applied automatically
Name the VCF instance and the management domain
Click Next

The VCF Management step collects the FQDNs for VCF Operations, the License Server, and the fleet, instance, and services-runtime components; this is where the pre-filled FQDNs from the Plan phase save the typing.

Enter the details of the existing vCenter: FQDN, administrator, and root credentials
Click Connect: the cluster running the vCenter appliance is selected as the deployment destination
Click Next

Provide the IP pools, a single IPv4 range works for both: minimum 12 addresses for the VCF Management Services pool and 5 for the VCF Automation pool
Click Next

Enter the NSX Manager cluster and appliance FQDNs
Decide on the overlay networking mode
Click Next

The Configure overlay using ESX Management VMkernel Networking toggle is one of my favorite quality-of-life items in 9.x: NSX 9 can run overlay over the ESX management VMkernel network without a VLAN-backed transport configuration. Unchecked, NSX is configured in VLAN transport zone mode instead.

Enter the SDDC Manager FQDN and the installer appliance password
Click Next

The info banner explains why the appliance password is requested: when the installer appliance runs on one of the management domain hosts, it is converted into the SDDC Manager appliance during deployment: the same appliance transition the official docs describe, and the reason the prerequisites page noted the SDDC Manager FQDN is optional in that placement.

Deploy

Review the summary, every section from the wizard is expandable here
Optionally click Download JSON Spec
Click Next

The JSON preview tab and the downloadable spec make the whole deployment repeatable: the same file drives API-based deployments, and it is the vehicle for the options the wizard does not expose, like dual-stack networking or an alternative internal cluster CIDR.

Wait for the 11 validation checks to complete: deployment specification, security configuration, DNS resolution, versions and bundles, existing SDDC Manager configuration, password policies, network configuration, existing components, and the capacity calculations
Resolve any errors, acknowledge warnings if appropriate, and click Deploy

From here the installer takes over: management services, VCF Operations, NSX, SDDC Manager conversion, and the rest of the management domain roll out in sequence. Depending on hardware, expect this to run for a few hours.

If validation or deployment fails

A few 9.1-specific failure modes worth knowing before you hit Deploy:

“Deploy and configure VCF Management Platform” fails: the management services use an internal cluster CIDR of 198.18.0.0/15 by default; if that overlaps your network, KB 440541 covers switching it to 240.0.0.0/15 or 250.0.0.0/15 via the JSON spec.
“VCF Management Services Deployment Task” fails on NTP: the NTP server must be reachable over UDP 123 from the deployed appliances, not just from the installer: KB 439240.
vMotion / vSAN network connectivity validations fail: the installer does not recognize standby uplinks; set the vmnics active/active or disable the check per KB 437248.
Uppercase FQDNs: deployment fails for fleet components, identity broker, services runtime, and VCF Automation; lowercase everything (known issues).

For nested labs, William Lam maintains a comprehensive set of installer workarounds for 9.1 (pNIC speed, vSAN HCL, and MTU prechecks included. And a neat trick from the same source: the installer doubles as a standalone pre-check tool) you can run the full validation suite against your infrastructure without deploying anything.

References

Official documentation

Broadcom KBs

My VCF 9.0 installer series

Upgrading VCF 9.1 Management Services to 9.1.0.0400 Step by Step

Cosmin Trif — Mon, 03 Aug 2026 10:00:00 +0000

On July 13, 2026 Broadcom shipped the next VCF 9.1 patch wave, and this post walks through the part of it that lives under Build -> Lifecycle -> VCF Management -> Upgrade: the VCF Management services. The headline releases on this surface are VCF Operations 9.1.0.0400 and VCF Automation 9.1.0.0200, mostly security enhancements plus a batch of fixes. This post is the follow-up to my 9.1.0.0300 walkthrough.

To be clear on scope: this post covers only the management services. SDDC Manager 9.1.0.0400 and the core components (vCenter, NSX, ESX, vSAN) go through the VCF Instances flow and are not covered here; see the short section at the end.

One thing to understand up front: patch releases are not synchronized among all VCF components, and you can pick and choose which components to apply. That is why my target list below is a mix of 0400, 0200, and 0100 builds. It looks odd the first time. It is expected.

Versions in This Update

Here is the full From/To picture from my lab, exactly as the VCF Operations UI reports it.

Component	Current Version	Target Version
Fleet Lifecycle	9.1.0.0300.25536195	9.1.0.0400.25570104
VCF Operations	9.1.0.0300.25531073	9.1.0.0400.25541561
VCF Operations for Networks	9.1.0.0100.25427421	9.1.0.0200.25517220
Identity Broker	9.1.0.0.25368698	9.1.0.0100.25522734
VCF Automation	9.1.0.0100.25429499	9.1.0.0200.25556825
Log Management	9.1.0.0100.25435121	9.1.0.0400.25544947
SDDC Lifecycle	9.1.0.0300.25536194	9.1.0.0400.25570103
Real-Time Metrics	9.1.0.0100.25435036	9.1.0.0400.25544944
Real-Time Metrics Store	9.1.0.0.25370367	9.1.0.0200.25555874
Salt Master	9.1.0.0100.25434834	9.1.0.0400.25544946
Salt RaaS	9.1.0.0100.25434834	9.1.0.0400.25544946
Software Depot	9.1.0.0.25371105	9.1.0.0400.25570105
Migration Service Engine	9.1.0.0.25370929	9.1.0.0200.25556825
VCF Services Runtime	9.1.0.0.25370367	9.1.0.0200.25555874

SDDC Manager 9.1.0.0400 (build 25570100) ships in the same wave but lives outside this component list. See the scope section at the end of the post.

Before You Start

A few rules before clicking anything. Back up your components before patching, and remember only one upgrade or patch operation can run at a time. That single-operation rule matters more than it sounds with fourteen components in the queue, plan for a long session or spread it over a maintenance window. If your depot is online, the binaries pull directly. If you run offline, update the VCF Download Tool to 9.1.0.0400 (build 25550178) first and download the binaries with it.

Two known issues shape how I ran this:

SDDC Lifecycle 9.1.0.0400: the batch precheck can fail with VCF_LCM_FLEET_UPGRADE_400_COMPONENT_NOT_NEEDED_USER_INPUT_SPEC_PROVIDED. Do not use Run Prechecks (ALL). Precheck each component individually.
Software Depot 9.1.0.0400: patching the depot takes it temporarily offline. Do not run any other component patch at the same time, and retry anything that failed afterwards.

Upgrade Fleet Lifecycle

Broadcom’s ordering guidance for maintenance releases starts with Fleet Lifecycle. For patch releases the order is flexible, but I still go Fleet Lifecycle first; it drives patch deployment for the rest of the fleet components.

In VCF Operations, go to Build -> Lifecycle -> VCF Management -> Upgrade. Open the “…” menu on the Fleet Lifecycle card and click Select version.

The Fleet Lifecycle Component Target Version dialog opens. Set the target to 9.1.0.0400.25570104.

Back on the card, the upgrade path now reads 9.1.0.0300.25536195 to 9.1.0.0400.25570104. Click Upgrade.

Kick off the upgrade. The card flips to Upgrade in progress.

Open Upgrade details. The first two subtasks are “Set Fleet lifecycle upgrade context” and “Stage Fleet lifecycle plugin in VCF services runtime”.

The status messages move through Staging binaries and Running Component Stage Prechecks. Nothing to do here but watch.

All 7 subtasks land on Completed. In this run the whole thing took about 45 minutes, 11:08 to 11:54 AM.

Set the VCF Management Target Version

With Fleet Lifecycle done, click CHANGE TARGET VERSION.

The Set Target Version dialog offers the VCF global version 9.1.0.*.

The component list now shows everything Ready for upgrade, with the mixed 0400/0200/0100 targets from the table above. This is the per-component patch numbering at work, not a depot problem.

Because of the SDDC Lifecycle known issue, I did not touch RUN PRECHECKS (ALL). I ran prechecks per component instead, right before each upgrade. It costs a few extra clicks per component, but it avoids the VCF_LCM_FLEET_UPGRADE_400_COMPONENT_NOT_NEEDED_USER_INPUT_SPEC_PROVIDED failure entirely.

Upgrade VCF Operations

First up, VCF Operations itself to 9.1.0.0400.25541561. Note that the cloud proxy and the license server are patched automatically as part of this one, no separate steps needed for either.

The workflow runs through its subtasks; I moved on once it was In Progress.

Upgrade Identity Broker

Next, Identity Broker to 9.1.0.0100.25522734.

This one is a 6-subtask workflow.

Upgrade VCF Automation

VCF Automation goes to 9.1.0.0200.25556825.

The precheck workflow runs first, then the upgrade takes over.

Upgrade VCF Operations for Networks

VCF Operations for Networks moves to 9.1.0.0200.25517220.

Upgrade Log Management

Log Management targets 9.1.0.0400.25544947.

Same pattern: precheck, then the upgrade workflow.

Upgrade SDDC Lifecycle

SDDC Lifecycle goes to 9.1.0.0400.25570103: the component behind the batch precheck known issue, upgraded here with its own individual precheck.

Upgrade Real-Time Metrics and Metrics Store

Real-Time Metrics targets 9.1.0.0400.25544944.

The Real-Time Metrics row switches to Upgrade in progress.

Then the upgrade workflow itself.

The Real-Time Metrics Store is a separate component; it targets 9.1.0.0200.25555874.

The Real-Time Metrics Store row switches to Upgrade in progress.

And the upgrade workflow follows.

Upgrade Salt Master

Salt Master targets 9.1.0.0400.25544946.

The Salt Master row switches to Upgrade in progress.

The upgrade workflow takes over and works through its subtasks.

Upgrade Software Depot

Software Depot goes to 9.1.0.0400.25570105. Per the known issue in the release notes, the depot goes briefly offline during its own patch, so avoid launching other component patches at the same time and retry anything that failed afterwards.

The Software Depot row switches to Upgrade in progress.

Then the upgrade workflow, while the depot is briefly unavailable.

Upgrade Migration Service Engine

Migration Service Engine targets 9.1.0.0200.25556825.

The Migration Service Engine row switches to Upgrade in progress.

Fun detail in the workflow panel: the staging task exposes the internal component name VCD_MIGRATOR: “Stage VCD_MIGRATOR plugin in VCF services runtime”.

Upgrade VCF Services Runtime

VCF Services Runtime goes to 9.1.0.0200.25555874.

The VCF Services Runtime row switches to Upgrade in progress.

Then the upgrade workflow with its subtasks.

Upgrade Salt RaaS

Salt RaaS ran last in my lab, targeting 9.1.0.0400.25544946.

At the time of this capture the precheck workflow was still running, “Run Salt RaaS upgrade prechecks” shows In Progress.

What About SDDC Manager and the Core Components?

They are out of scope for this post. SDDC Manager 9.1.0.0400 (build 25570100) and the core components from this wave (ESX 9.1.0.0200, vSAN 9.1.0.0200, NSX 9.1.0.0200, and vCenter 9.1.0.0200, later bumped to 9.1.0.0300 on July 29, 2026) are applied through Build -> Lifecycle -> VCF Instances. That is the same flow I documented in Upgrading VCF 9.1 to 9.1.0.0300 Step by Step.

Validate the Update

Before calling it done:

Check the Component Versions page, every patched management component should show On Target.
Check the task list, no failed workflows left behind.
Confirm the VCF Operations UI is reachable and healthy.
Retry anything that failed while the Software Depot was being patched; the depot was offline during that window.

For SDDC Manager and the core components, see the previous section, the flow in Upgrading VCF 9.1 to 9.1.0.0300 Step by Step still applies one-to-one.

Fixing Swagger’s localhost:8600 URL in VCF Automation 9.1

Cosmin Trif — Fri, 31 Jul 2026 00:00:00 +0000

While putting together the VCF Automation 9.1 API getting started post, I spent some time in the in-product API Help Center. Log into the VM Apps tenant, click your username, API Help Center > Explore Automation APIs. The Swagger pages render fine, but the moment you try an actual call, it fails. The Servers box for the VCF Automation (Blueprint) API shows:

http://localhost:8600

Swagger UI builds Try It Out requests from servers[0].url, so the browser dutifully sends every request to port 8600 on your own workstation. Connection refused, every time. The documentation is correct; the advertised host is not.

This post is about finding where that value actually comes from (which took three wrong turns through the appliance’s Kubernetes internals) and the override that finally fixed it without touching a container image. The short version:

The localhost:8600 value is not in any configuration on the appliance. A grep across a full support-bundle cluster dump finds no ConfigMap, Helm value, gateway route, or forwarded-headers setting that produces it.
The spec is a static JSON file generated by springdoc at build time (the giveaway is its "description": "Generated server url") and it ships as a classpath resource inside the Spring Boot application in the tango-blueprint-service-app pod. Whoever built it had the service listening on port 8600, and the URL froze there.
The api-docs page itself is served by a different pod than the spec, which is why the obvious nginx-level fixes go nowhere.
The fix: mount a corrected copy of the spec from a ConfigMap and prepend file:/override/ to spring.web.resources.static-locations via JAVA_OPTS, so Spring serves the fixed file and never falls through to the copy shipped in the image. Survives pod restarts with nothing to reconcile it away; a product upgrade will wipe it.

Everything below was done on a lab appliance running build 9.1.0.0100.25429499. This is an unsupported modification. More on that at the end.

The Symptom

In the tenant API Help Center, open the VCF Automation API (the Blueprint one, version 2019-09-12). The spec renders, the paths are all correct, but the servers dropdown offers exactly one entry: http://localhost:8600. There is no way to type a different URL: the dropdown only lists what the spec declares, and this spec declares one hardcoded server with no variables.

Browser DevTools (Network tab) shows what the page actually loads. First an index of every API the Help Center knows about:

/tenant/<your-tenant>/api-docs/assets/content/soft/automation-apis.json

That index maps each tile to a spec URL: about sixteen specs across a dozen backend services. The Blueprint entry points at:

/blueprint/api-docs/classic-apis/api-doc-public-classic-vra-2019-09-12.json

And that document contains the problem, verbatim:

"servers": [
 {
 "url": "http://localhost:8600",
 "description": "Generated server url"
 }
]

Two details in that response are worth pausing on, because they shaped the whole investigation:

"Generated server url" is the literal default description springdoc attaches when it auto-computes the server URL from the incoming request. So springdoc generated this, but if it were computed per request, it would show the appliance FQDN, not localhost.
The response carries a last-modified date from months before I ever opened the page, plus accept-ranges: bytes. That is a static file being read off disk (or classpath), not a document rendered per request.

Put together: someone ran the Blueprint service on a build machine, where it listened on localhost:8600, exported the generated spec to a file, and shipped that file in the product. The URL froze at build time.

Ruling Out Configuration

Before touching anything, I wanted to know whether some appliance setting produces or rewrites that value, because if it did, that would be the supported place to fix it.

It does not. I had a full support bundle from this appliance handy (that is a story for another post), and the extracted cluster object dump is conclusive:

The string 8600 appears nowhere in the cluster as a port, URL, or config value. No Service exposes it, no container declares it, no ConfigMap mentions it. The only matches are UID substrings.
There is no springdoc, server.forward-headers-strategy, or server-URL configuration in any ConfigMap in the prelude or vmsp-platform namespaces.
The Envoy gateway routes (Gateway API HTTPRoute objects) that publish the api-docs paths perform path rewrites only: nothing rewrites hosts or response bodies.

So there is no knob. The value lives in content, not configuration, and only Broadcom can fix it properly. Everything from here on is about making the appliance serve a corrected copy.

Wrong Turn #1: The Pod That Serves the Page Doesn’t Serve the Spec

The api-docs page shell (the Angular app with the tiles) is served by the cloud-automation-ui-app pod in the prelude namespace. Its nginx config (ConfigMap cloud-automation-ui) rewrites /tenant/<org>/api-docs and /provider/api-docs into static content under /usr/share/nginx/html/dist. My first instinct was an nginx sub_filter there, rewriting localhost:8600 in responses.

Dead end, for a structural reason: the spec never passes through that pod. The gateway routes the two URLs to different backends entirely:

Path	HTTPRoute	Backend
`/tenant/<org>/api-docs/...` (the page, the index JSON)	`tenant-in-path-automation-ui`	`cloud-automation-ui`
`/blueprint/api-docs/...` (the spec)	`blueprintapi-docs`	`tango-blueprint:8080`, prefix rewritten to `/api-docs/`

A sub_filter in the UI pod would rewrite a response it never sees. The actual owner of the spec is the Blueprint service itself: Deployment/tango-blueprint-service-app, image blueprint-webapp:9.1.0.0100.25429499: a Spring Boot app, which also explains the Spring Security headers on the spec response.

Wrong Turn #2: There Is No File to Edit

Fine, exec into the right pod and sed the file in place:

kubectl -n prelude exec deploy/tango-blueprint-service-app -- \
 sh -c 'find / -name "api-doc-public-classic-vra-*.json" -not -path "/proc/*" 2>/dev/null'

Nothing. And looking for the application itself:

kubectl -n prelude exec deploy/tango-blueprint-service-app -- \
 sh -c 'find / -maxdepth 3 -name "*.jar" -not -path "/proc/*" 2>/dev/null | head'

/opt/bc-fips/bcutil-fips-2.1.5.jar
/opt/bc-fips/bctls-fips-2.1.22.jar
/opt/bc-fips/bcpkix-fips-2.1.10.jar
/opt/bc-fips/bc-fips-2.1.2.jar
/opt/bc-fips/bcmail-fips-2.1.6.jar
/jdk/lib/jrt-fs.jar

Only the Bouncy Castle FIPS libraries and the JDK, the shallow search doesn’t even turn up the application archive itself. Wherever the application lives, the spec is packaged inside it as a classpath resource: find sees nothing, and sed has nothing to reach. Even if you dug out the archive, patched it, and re-packed it in the running container, the fix would be pointless: the JVM holds it open, so a restart is needed to pick up the change, and the restart is exactly what rebuilds the container filesystem from the pristine image. The fix would erase itself at the moment of application.

Wrong Turn #3: kubectl edit Ate My JAVA_OPTS

The mechanism that does work is Spring’s static resource resolution. Spring Boot serves static content from an ordered list of locations, and the first location that contains a matching file wins:

spring.web.resources.static-locations =
 classpath:/META-INF/resources/, classpath:/resources/, classpath:/static/, classpath:/public/

Setting that property replaces the default list. So if I prepend a filesystem directory and re-append the defaults, a file I control shadows the identically-pathed resource on the application classpath, and everything else keeps being served from the classpath exactly as before.

The path arithmetic works out neatly. After the gateway’s prefix rewrite, the backend sees the request as /api-docs/classic-apis/api-doc-public-classic-vra-2019-09-12.json. With file:/override/ first in the list, Spring checks /override/api-docs/classic-apis/api-doc-public-classic-vra-2019-09-12.json before falling through to the classpath. That is exactly where a ConfigMap mount can put a corrected copy.

The wrong-turn part: my first attempt applied all of this with kubectl edit deploy. The volume and volumeMount saved; the JAVA_OPTS append silently did not. That env value is one enormous line that already contains $(SERVICE_ACCOUNT_SECRET) (literal Kubernetes variable-expansion syntax) and somewhere in the editor round-trip the appended text was lost; I never pinned down exactly where. (The same string is also a shell command-substitution landmine if you ever round-trip the value through a shell, which is why the fix below patches programmatically.) The pod rolled, the override directory appeared, and the spec still said localhost:8600 because the JVM never got the property. Verify the property reached the Deployment before concluding the approach failed.

The Fix

All commands run as root on the appliance, where kubectl is already configured. Replace vcfa.domain.com with your appliance FQDN.

1. Produce the corrected spec. No spelunking inside the image needed, pull it through the gateway and fix the one string:

curl -sk https://vcfa.domain.com/blueprint/api-docs/classic-apis/api-doc-public-classic-vra-2019-09-12.json \
 | sed 's|http://localhost:8600|https://vcfa.domain.com|g' \
 > /root/api-doc-public-classic-vra-2019-09-12.json

Sanity-check it: zero remaining hits, and still valid JSON:

grep -c localhost:8600 /root/api-doc-public-classic-vra-2019-09-12.json
python3 -m json.tool /root/api-doc-public-classic-vra-2019-09-12.json > /dev/null && echo "valid json"

2. Create the ConfigMap and back up the Deployment:

kubectl -n prelude create configmap blueprint-apidocs-override \
 --from-file=/root/api-doc-public-classic-vra-2019-09-12.json

kubectl -n prelude get deploy tango-blueprint-service-app -o yaml \
 > /root/tango-blueprint-deploy.backup.yaml

3. Add the volume and mount. A strategic merge patch merges named list entries, so this adds without disturbing the existing volumes and mounts:

kubectl -n prelude patch deploy tango-blueprint-service-app --type=strategic -p '
spec:
 template:
 spec:
 volumes:
 - name: apidocs-override
 configMap:
 name: blueprint-apidocs-override
 containers:
 - name: tango-blueprint-service-app
 volumeMounts:
 - name: apidocs-override
 mountPath: /override/api-docs/classic-apis
'

4. Append the properties to JAVA_OPTS (programmatically. This reads the current value, appends both the current (spring.web.resources.static-locations) and the pre-2.4 (spring.resources.static-locations) property names) whichever one this Spring Boot generation ignores does no harm, and writes a JSON patch. It refuses to double-apply:

kubectl -n prelude get deploy tango-blueprint-service-app -o json > /root/d.json

python3 - <<'EOF'
import json
d = json.load(open("/root/d.json"))
env = d["spec"]["template"]["spec"]["containers"][0]["env"]
i = [n for n, e in enumerate(env) if e["name"] == "JAVA_OPTS"][0]
loc = "file:/override/,classpath:/META-INF/resources/,classpath:/resources/,classpath:/static/,classpath:/public/"
add = " -Dspring.web.resources.static-locations=" + loc + " -Dspring.resources.static-locations=" + loc
if "static-locations" in env[i]["value"]:
 json.dump([], open("/root/patch.json", "w"))
 print("already present - nothing to do"); raise SystemExit
json.dump([{"op": "replace",
 "path": "/spec/template/spec/containers/0/env/%d/value" % i,
 "value": env[i]["value"] + add}],
 open("/root/patch.json", "w"))
print("patch written for env index", i)
EOF

kubectl -n prelude patch deploy tango-blueprint-service-app --type=json --patch-file=/root/patch.json

5. Wait for the rollout. The Deployment uses the Recreate strategy with a single replica, so the Blueprint service is briefly down while the pod is replaced:

kubectl -n prelude rollout status deploy/tango-blueprint-service-app --timeout=180s

Verification

Learned from wrong turn #3: verify each layer, not just the end result.

The property is on the Deployment:

kubectl -n prelude get deploy tango-blueprint-service-app \
 -o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="JAVA_OPTS")].value}' \
 | tr ' ' '\n' | grep -i static

-Dspring.web.resources.static-locations=file:/override/,classpath:/META-INF/resources/,...
-Dspring.resources.static-locations=file:/override/,classpath:/META-INF/resources/,...

The override file is mounted in the new pod:

kubectl -n prelude exec deploy/tango-blueprint-service-app -c tango-blueprint-service-app -- \
 ls -la /override/api-docs/classic-apis/

And the actual test, the spec as served through the gateway:

curl -sk https://vcfa.domain.com/blueprint/api-docs/classic-apis/api-doc-public-classic-vra-2019-09-12.json \
 | grep -A2 '"servers"'

 "servers": [
 {
 "url": "https://vcfa.domain.com",

Hard-reload the API Help Center page (the SPA caches aggressively) and the Servers box shows the appliance FQDN. Try It Out now sends requests where they belong.

What This Does and Does Not Fix

Worth being precise here, because the Help Center is bigger than one spec:

Fixed: the 2019-09-12 Blueprint spec shown above. Its 2019-01-15 sibling from the same /blueprint/api-docs/classic-apis/ directory - if it shows the same URL - is the same fix: repeat step 1 for it, then rebuild the ConfigMap with both files: kubectl -n prelude create configmap blueprint-apidocs-override --from-file=/root/api-doc-public-classic-vra-2019-09-12.json --from-file=/root/api-doc-public-classic-vra-2019-01-15.json --dry-run=client -o yaml | kubectl -n prelude replace -f -. The mounted volume picks up the change on its own within a minute or so; no restart needed.
Same pattern, different pod: the catalog, deployment, and policies tiles point at api-doc-public-classic-vra-*.yaml files under /catalog/api-docs/classic-apis/ - the same baked-file shape, owned by the catalog service. If those show the same URL, it is the same fix against that Deployment.
Possibly not broken at all: several tiles point at live springdoc endpoints (/identity/doc/v3/api-docs, /iaas-api/swagger/v3/api-docs/..., /project-service/api/swagger/v3/api-docs/...). Those generate their spec per request, so check before assuming. A quick curl ... | jq .servers against each URL from the index tells you which ones need attention.

Caveats

This is an unsupported modification to a Broadcom appliance, and it behaves accordingly:

It survives pod restarts, and nothing reconciles it away. The fix lives in the Deployment spec, so every pod the Deployment creates from now on gets the mount and the property - the verified state above is itself a freshly recreated pod. The tango-blueprint-service Helm release is deployed once at install/upgrade time with nothing reconciling it continuously, so it should come back intact after an appliance reboot as well; re-check the spec once after your next reboot to confirm. (Do not assume this generalizes: several other components in the same namespace are Flux-managed and would revert an edit within minutes.)
A product upgrade will wipe it. The LCM re-renders the Deployment from the new chart. Expect to re-apply, and re-check after any lifecycle operation.
Roll back at any time with the backup from step 2. Not with kubectl apply, though - the backup carries the pre-patch resourceVersion (so the apply is rejected as a conflict), and client-side apply against a Helm-created object has no last-applied-configuration to prune from, so the added volume would survive the merge and the next pod would wedge on the then-deleted ConfigMap. kubectl replace does a full PUT and removes the volume, mount, and JAVA_OPTS additions in one shot; strip the resourceVersion so the PUT is unconditional, and delete the ConfigMap only after the Deployment no longer references it:

sed '/^ resourceVersion:/d' /root/tango-blueprint-deploy.backup.yaml \
 | kubectl -n prelude replace -f -
kubectl -n prelude rollout status deploy/tango-blueprint-service-app --timeout=180s
kubectl -n prelude delete configmap blueprint-apidocs-override

File an SR anyway. As of this writing there is no KB and nothing in the 9.1 release notes for this - the proper fix has to ship in the product, and that only happens if it gets reported. Reference the build number and the "Generated server url" value in the spec.

If you only need a working Try It Out for yourself and would rather not touch the appliance at all, there is a zero-footprint alternative: download the spec, fix servers[0].url in the copy, and import it into Postman; it seeds the collection’s baseUrl from the spec, and auth works as described in the getting started post.

Final Notes

The frustrating part of this bug is how little is actually wrong: every path in the spec is correct, authentication is correct, the API itself works. One string, frozen at build time on some build machine where the Blueprint service happened to listen on port 8600, breaks the one feature the page exists to provide.

The investigation pattern is the reusable part. When a value appears in a rendered page and nothing in the configuration produces it, stop grepping ConfigMaps and follow the bytes instead: DevTools tells you the exact URL, the response headers tell you whether it is static or generated, and the gateway routes tell you which pod actually owns it. In this case each of those three steps invalidated an otherwise-reasonable fix (the nginx rewrite targeted the wrong pod, the in-pod sed targeted a file that does not exist, and the editor-based patch failed silently) before the resource-shadowing approach landed on the one layer where the platform genuinely offers an override.

References

VCF Automation 9.1 API Getting Started: authentication against the same appliance, and where the API docs moved in 9.1
Broadcom TechDocs - What Are the Automation APIs and How Do I Use Them (VCF 9.1)
VM Apps Org APIs on the Broadcom Developer Portal, the hosted alternative to the in-product Help Center
Spring Boot Reference - Serving Static Content, the static-locations resolution order this fix relies on
springdoc-openapi FAQ; how the “Generated server url” value is computed, and why it goes stale behind a proxy