Patching Standalone ESXi: A Lab Runbook Built Around Recovery

Historical field note: This runbook records a standalone ESXi 7.x lab workflow. Depot locations, entitlement requirements, supported hardware, and profile names change. Confirm the current Broadcom documentation and lifecycle status before using these commands.

Command-line patching is useful when a standalone ESXi host does not have the lifecycle tooling available in a larger vSphere environment. 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:

1. Can the workloads tolerate the maintenance window?
2. Can I reach the host if normal management access fails?
3. Is the target image compatible with the hardware and installed VIBs?
4. 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=true
esxcli system maintenanceMode get
vmware -v

If the host cannot enter maintenance mode cleanly, resolve that condition rather than forcing the patch forward.

Prefer a reviewed offline bundle

The original lab procedure used VMware’s public online depot. That endpoint no longer resolves, and current Broadcom guidance directs administrators to obtain an authorized offline bundle through the support portal and upload it to a datastore accessible to the host.

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

Run the transaction as a dry run first:

esxcli software profile update \
  --depot=/vmfs/volumes/<datastore>/<directory>/<offline-bundle>.zip \
  --profile=<approved-profile> \
  --dry-run

Read the output. Dependency conflicts, removed VIBs, acceptance-level changes, and hardware warnings are decision inputs, not noise to bypass.

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:

reboot

After the host returns, verify more than the version number:

vmware -v
esxcli software profile get
esxcli system maintenanceMode get

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

I use the same recovery-first approach when clearing an Ubuntu boot volume: keep a known-good path before reclaiming 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.

Sources and disclosures

• Broadcom: patching an ESXi host using the command line
• Broadcom: upgrading an ESXi host with an offline bundle

This is a historical lab runbook, not current vendor guidance. It is not affiliated with or endorsed by Broadcom or VMware. Validate lifecycle status, entitlements, hardware compatibility, image profiles, and recovery procedures for the exact environment before use.