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 targetWhat the current table shows
ESXi 7.0 Update 3f, build 20036589Later 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 24280767Later releases exist in the 8.0 Update 3 train, including Update 3k, build 25595708.
ESX 9.0 GA, build 24755229Later 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:

  1. Confirm the supported upgrade path in the Broadcom Product Interoperability Matrix, including vCenter Server, NSX, vSAN and every integrated VMware product.
  2. 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.
  3. 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.
  4. 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.
  5. 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