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. ...

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. ...

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. ...

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. ...

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: ...

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. ...

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. ...

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. ...

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. ...

Back in 2022 I wrote vRA 8 API getting started, two curl calls and you had a bearer token. Since then the product has been renamed twice (vRealize Automation → VMware Aria Automation → VCF Automation) and, more importantly for anyone with scripts in production, the authentication flow changed in VCF 9.x. Neither of the two calls from that post works against a 9.1 appliance. This is the 9.1 version of the same post: the minimum you need to do before you can actually query the API, with curl. ...