Historical field note: This runbook was developed from a standalone ESXi 7.x command-line workflow. Broadcom’s current profile-based offline-bundle procedure also covers ESXi 8.x. The recovery and verification discipline applies to standalone hosts in enterprise environments as well as smaller ones. For a host managed through vCenter and vSphere Lifecycle Manager, follow the approved lifecycle process rather than bypassing it. Depot locations, entitlement requirements, supported hardware, firmware, OEM images, installed VIBs, and profile names change; confirm the current Broadcom documentation, release notes, and lifecycle status before using these commands.
Command-line patching is useful for an approved standalone-host change when vCenter lifecycle management is unavailable or does not apply. It is also easy to reduce the work to a single esxcli command and miss the controls that make the change safe.
The sequence I use is built around four questions:
- Can the workloads tolerate the maintenance window?
- Can I reach the host if normal management access fails?
- Is the target image compatible with the hardware and installed VIBs?
- What evidence will prove that the update succeeded?
Prepare the recovery path
Before changing the host:
- Shut down or migrate every virtual machine cleanly.
- Back up the host configuration and the workloads through an independent path.
- Verify console or out-of-band access.
- Record the current ESXi build, image profile, storage state, and hardware warnings.
- Select a profile supported for the exact server and driver combination.
Enter maintenance mode and verify it:
esxcli system maintenanceMode set --enable=trueesxcli system maintenanceMode getvmware -vIf the host cannot enter maintenance mode cleanly, resolve that condition rather than forcing the patch forward.
Use an approved offline bundle
Current Broadcom guidance for command-line patching starts with an approved patch or image from its support portal, uploaded to a datastore accessible to the host. Use the approved offline bundle and target profile from the change plan; do not make the maintenance window depend on an external depot being reachable.
Using an offline bundle also avoids opening general outbound HTTP access from the hypervisor during the maintenance window. Verify the bundle’s source and integrity through the approved software-distribution process, then record its exact datastore path and target image profile in the change plan.
Discover, select, and simulate
List the profiles available to the host, then choose an exact profile based on the approved target—not simply the largest version string:
esxcli software sources profile list \ --depot=/vmfs/volumes/<datastore>/<directory>/<offline-bundle>.zipRun the transaction as a dry run first:
esxcli software profile update \ --depot=/vmfs/volumes/<datastore>/<directory>/<offline-bundle>.zip \ --profile=<approved-profile> \ --dry-runRead the output. Dependency conflicts, removed VIBs, acceptance-level changes, and hardware warnings are decision inputs, not noise to bypass.
Retain the dry-run output in the approved change record before applying the update. It gives the post-change reviewer a baseline for the transaction that was actually approved.
Apply and close the maintenance window
If the dry run matches the approved change:
esxcli software profile update \ --depot=/vmfs/volumes/<datastore>/<directory>/<offline-bundle>.zip \ --profile=<approved-profile>Reboot when the transaction requires it:
rebootAfter the host returns, verify more than the version number:
vmware -vesxcli software profile getesxcli system maintenanceMode getCheck management connectivity, datastores, physical NICs, storage adapters, time synchronization, and a representative workload before exiting maintenance mode.
Lessons learned beyond one hypervisor
Patch reporting often collapses the work into one percentage. On the host, success depends on drivers, storage, management access, workload behavior, and a route back when one of those pieces fails. I want both facts in the record: the approved update landed, and the service returned in a known-good state.
The syntax will be different on another platform, but the sequence holds up: secure the recovery path, review compatibility, simulate where the tooling allows it, apply one approved target, and test the service after the change. A completed package transaction is a checkpoint, not the outcome.
The same recovery-first approach applies when reclaiming boot volume capacity: keep a known-good path before removing or replacing anything.
For each change, retain the original build and compatibility state, the approved target, the dry-run output, the actual transaction, and the post-reboot checks. Someone reviewing the record later should be able to tell what changed and why the host was returned to service.
