This historical lab procedure updated an ESXi 8 host to ESXi 8.0 Update 3b, build 24280767, with esxcli. Review the ESXi 8.0 U3b release notes and confirm compatibility before continuing.
Broadcom’s build-number table now records later releases in the 8.0 Update 3 train, including Update 3k, build 25595708. The profile in this article remains the pinned historical target, not a current release recommendation.
Prepare the Host and Enter Maintenance Mode
Do not apply an image profile while the host is carrying workloads. Broadcom’s current esxcli patching procedure requires maintenance mode before esxcli software profile update.
Before continuing:
- Confirm the target ESXi release, server firmware, hardware, vCenter Server and integrated products are compatible. Use the hardware vendor’s custom image when required.
- Back up the ESXi host configuration and verify the recovery path.
- Migrate or shut down every user VM. DRS can evacuate workloads when configured; do not manually power off or migrate vCLS VMs unless Broadcom Support directs you to do so.
- Confirm that the remaining cluster can satisfy the intended vSphere HA failover policy while this host is unavailable.
- For vSAN, verify cluster health and object compliance, confirm there are no active resynchronizations, select the data-migration option appropriate to the storage policies and available capacity, and wait for evacuation to finish. Do not choose No data migration without understanding the resulting availability risk.
- If the host is NSX-prepared, follow the matching NSX kernel-module and upgrade requirements in Broadcom KB 312013. VCF-managed environments should use the supported VCF lifecycle workflow.
Enter maintenance mode from the vSphere Client, then confirm the state from the ESXi shell:
vim-cmd hostsvc/hostsummary | grep inMaintenanceMode
Continue only when the result is true. Unless the validated design explicitly supports parallel remediation, patch one host at a time.
The original walkthrough queried a shared public online depot that Broadcom has retired. The executable legacy URL has been removed. For a current online procedure, use the authenticated Broadcom depot follow-up. To reproduce this specific historical target when the artifact is still available to an entitled account, download the matching offline depot bundle, upload it to a datastore and set its path:
OFFLINE_BUNDLE='/vmfs/volumes/DATASTORE/updates/ESXI_8U3B_DEPOT_BUNDLE.zip'
esxcli software sources profile list -d "$OFFLINE_BUNDLE"
This returned a list of updates that were available:
At the time of this lab, I deliberately selected ESXi-8.0U3b-24280767-standard. That exact profile is the article’s historical target; it is not a moving “latest” profile and has since been superseded.
After verifying the bundle and exact profile name, I reviewed a dry run and then applied that pinned target:
esxcli software profile update --dry-run -p ESXi-8.0U3b-24280767-standard -d "$OFFLINE_BUNDLE"
Only after the dry-run output was clean did I run the live update separately:
esxcli software profile update -p ESXi-8.0U3b-24280767-standard -d "$OFFLINE_BUNDLE"
If you run in to the below error follow my other post here:
Once the upgrade was complete I was presented with this output:
The installation reported that a reboot was required, so I rebooted the server while it remained in maintenance mode.
After the server was back up, ESXi reported build 24280767.
Validate and Exit Maintenance Mode
Confirm the build and active image profile, then validate management networking, storage paths and cluster health before returning the host to service:
vmware -vl
esxcli software profile get
For a vSAN host, wait for any post-reboot resynchronization to complete and confirm object health. For an NSX-prepared host, confirm its transport-node and datapath status. When validation succeeds, exit maintenance mode from the vSphere Client or run:
vim-cmd /hostsvc/maintenance_mode_exit