ESXi Manual Update

原文：ESXi Manual Update — theDXT (Daniel Keer)

You can upgrade your ESXi very easily with vCenter but if you don’t have that, well then here is how you can do it manually. Every host eventually needs the manual path — a standalone host with no vCenter, an air-gapped lab, a host whose Lifecycle Manager is out of step with the depot, or a cluster where the update manager cannot reach the internet and you need the update applied tonight. This guide covers the whole job with esxcli: the depot and offline bundle formats, how to get the file onto the host, how to protect the configuration before you change anything, how to apply the update properly, and how to get back if it goes wrong.

When you need the manual method

Lifecycle Manager inside vCenter is the supported, comfortable way to patch a fleet: it handles baselines, staging, remediation order and compliance reporting. It is also unavailable in a surprising number of real situations:

• Standalone hosts. A single ESXi host with no vCenter at all, typically the host you use for a management VM or a small site.
• Air-gapped or restricted networks. No route to the Broadcom/VMware depot, so updates arrive as files on a USB stick or a datastore rather than from a repository.
• A host that is out of the managed inventory. A host disconnected from vCenter, or one whose vCenter is itself being rebuilt, still needs patching.
• Targeted driver or VIB work. When you need one specific component updated rather than the whole image profile, the command line gives you exact control.
• Recovery. Rebuilding a host from scratch before it has been added back to vCenter.

If the host is managed and vCenter is healthy, use Lifecycle Manager — fewer moving parts, better logging, and it is the path supported by the vendor. The manual method described here is the same engine under the hood, driven directly.

Prerequisites and pre-flight checks

• The right update level. Know exactly which build you are going to, and confirm it is compatible with the host's CPU generation, its storage and network drivers, and any vendor custom image (Dell, HPE, Lenovo and others ship their own depots with their own driver bundles).
• A backup of the ESXi configuration. This is the single most important step. The configuration backup captures the host's settings — networking, storage, users, services, license, certificates — as a downloadable bundle that you restore after a rebuild.
• Out-of-band access. You are rebooting a host over SSH. Have iDRAC, iLO, XClarity Controller or an IPMI/KVM path ready so that if the host does not come back on the network, you can watch it and fix it without driving to the site.
• Maintenance window and evacuation plan. Decide in advance whether you are migrating VMs to another host or shutting them down. If the host is powered down, make sure whatever runs on it is allowed to stop.
• Console access and credentials. The host's root password, plus a working vSphere Client or DCUI session.
• Space. Enough free space on the target datastore for the bundle, and enough free space on the host's /tmp and scratch partitions for the extraction and staging.

Step 1 — Download the depot or offline bundle

• Download the depot file you need from here https://www.vmware.com/patchmgr/findPatch.portal

With VMware the depot files contain the VIBs and image profiles (basically everything you need). You can read more about it here.

The naming convention tells you what you have. A file ending -depot.zip is a full depot containing the image profiles and all the VIBs that make up a complete ESXi build. A file named VMware-ESXi-7.0U1c-17325551-depot.zip is the 7.0 Update 1c release, build 17325551. Some downloads are component packages rather than full images — a single async driver, a tools VIB, a firmware bundle wrapper. Know which one you downloaded before you start typing commands, because the install syntax differs.

Verify the checksum. Compare the SHA-256 of the downloaded file against the value published with the release. A truncated download over a flaky link is a classic cause of a confusing esxcli error partway through an install.

Step 2 — Upload the offline bundle to a datastore

• Upload the offline bundle into a datastore (make a note of the full filename)

* Take a backup of your ESXi config. (Here’s how)

Upload with the vSphere Client's datastore browser, or with SCP if you prefer the command line. Then note the full path, because that is what you will pass to esxcli — datastore name, folder, and exact filename including the version and build number. A typo here produces an unhelpful "file not found" that costs you ten minutes of staring at the console.

If you have no vCenter and no datastore browser, you can also drop the bundle onto the host's scratch or a local datastore directly over SCP, or serve it from an HTTP location and let esxcli fetch it with the --server option.

Step 3 — Back up the configuration

Take the configuration backup before anything else. From the vSphere Client this is Host → Actions → Connection → Export System Configuration. From the console it is the equivalent of the DCUI's backup/restore option. Store the resulting bundle somewhere that is not this host.

If you already keep automated copies of host configuration, all the better — vCenter ESXi Config Backup Script shows how to keep a rolling backup without remembering to click the button. The point is that after the update you have a known-good description of how this host was configured, so a failed update is a restore rather than a redesign.

Step 4 — Evacuate the VMs and enter maintenance mode

• Depending on your setup either migrate the VMs or turn them off
• Put the host into maintenance mode by right clicking on the host and selecting Enter maintenance mode

* Click on Yes to confirm

Maintenance mode stops the host from accepting new VM placements and lets DRS drain it. What it does not do is power off anything still running locally — if a VM cannot be migrated, maintenance mode will sit at "entering maintenance mode" indefinitely. Resolve that first. Update and reboot a host with running VMs on it and you will find out what those VMs' recovery plans look like.

Step 5 — Enable SSH on the host

• Enable SSH by right clicking on the host and selecting Services > Enable Secure Shell

Turn it on for the window and turn it off when you are done. On a standalone host with no vCenter, use the DCUI (the yellow and grey console screen) — press F2, log in, and enable SSH from the Troubleshooting Options menu. Also confirm the host is not in lockdown mode, or that the account you are using is on the exception users list; lockdown mode will reject SSH and API access.

Step 6 — SSH in and install the update

• SSH into the host
• you will now need to run a command similar to this

esxcli software vib install -d /vmfs/volumes/RAID10/update/VMware-ESXi-7.0U1c-17325551-depot.zip

Everything after volumes will depend on your setup. I placed my file in a Datastore named RAID10 in a folder called update and the update I’ll be installing is VMware-ESXi-7.0U1c-17325551-depot.zip

A few notes on this command, because the syntax trips people up:

• vib install installs the VIBs contained in the depot. It does not change the host's image profile, so the build number reported by the host may not match the depot you applied. When you want the host to actually become that release, use the profile form instead: esxcli software profile update -d /vmfs/volumes/RAID10/update/VMware-ESXi-7.0U1c-17325551-depot.zip -p ESXi-7.0U1c-17325551-standard, replacing the profile name with the exact one listed by esxcli software sources profile list -d <bundle>.
• Add --dry-run to see what the command would do — which VIBs go up, which go down, which are being removed — without touching the host. There is no reason not to do this on a production host.
• Add --no-sig-check only if you genuinely must accept an unsigned VIB, and understand that you are disabling the verification that protects you from a corrupted or tampered package.
• If the host is in lockdown mode or the acceptance level is too strict for the VIBs in the package, the command fails with a specific message that names the VIB and the level. Raise the acceptance level deliberately or get a properly signed build.

• Wait for it to do it’s thing

It will then show you the installation result and you will likely need to reboot

* just type reboot

reboot

Do not reboot until the command returns a success result. A partial install followed by a reboot is how a host ends up unable to boot, and recovering from that generally means reinstalling ESXi and restoring the configuration backup — which is why step 3 exists.

Step 7 — Wait for the host to come back

• Wait for the host to come back after the reboot (I like to monitor the host with IPMI)

Watch the out-of-band console rather than pinging blindly. The boot sequence tells you immediately whether you are looking at a healthy host, an ESXi boot failure, or a machine that is stuck before the hypervisor even loads. For Lenovo hardware, the XClarity Controller is the equivalent of iDRAC and iLO, and the out-of-band comparison in iDRAC vs iLO vs IPMI is worth reading if you manage a mixed fleet. If the host comes back but with unexpected hardware alerts, check the vendor's own update tooling before assuming ESXi is at fault.

Step 8 — Verify and exit maintenance mode

• Once the host is online you can exit maintenance mode by right click on the host and selecting Exit maintenance mode

Before you exit maintenance mode, or immediately after, confirm the host really is on the build you intended and that nothing important broke:

esxcli system version get
esxcli software vib list | head -40
vmware -v

esxcli system version get gives the version, build and update level. vmware -v gives a one-line answer that is easy to paste into a change record. Then check the parts of the host that a failed update damages first: that the management network is up and reachable, that the datastores are visible and the volumes are mounted, that the vSwitch and port groups survived, that the host is not reporting a failed VIB or a degraded service, and that the vendor agents and any HBA firmware tools still load. If the host had a vSAN, NSX or other distributed component, verify that component's own health checks before you trust the host again.

Finally, disable SSH again, and re-enable it only when the next change window needs it.

Rollback and recovery

ESXi has no snapshot-based rollback for an update. Your options, in order of increasing pain:

1. Go forward to a different build. If the new build is the problem and the depot for the previous one is available, run the same profile update command with the older depot. ESXi does allow downgrades this way, subject to the VIB acceptance level. This is the fastest fix for "the new build broke a driver".
2. Remove or swap the offending VIB. For a single component, esxcli software vib remove -n <vibname> removes it and then you reboot. Useful for a bad async driver, dangerous if the VIB is part of the base image.
3. Reinstall and restore. If the host does not boot, reinstall ESXi from an ISO at the version you want, then restore the configuration bundle from step 3. This returns the host to a known state in well under an hour if the backup is current — and takes a full rebuild if it is not.

The configuration backup is what makes option three survivable, so treat step 3 as non-negotiable, not as best practice.

FAQ and common problems

The command fails with a dependency error. The VIB you are installing needs a version of another VIB the host does not have, or has a newer one. Use --dry-run to see the resolved plan, and prefer a full depot at the target release over mixing component packages from different builds.

No space left on device. The extraction needs space on the host's filesystem, not just the datastore. Free space in /tmp and the scratch location, or set a larger scratch partition, and retry.

The build number did not change. You almost certainly used vib install instead of profile update. Firmware and VIBs changed but the host did not adopt the new image profile. Re-run with the profile form against the depot.

Can I update firmware this way? No. The ESXi depot updates the hypervisor. Firmware is applied from the host's out-of-band controller or the vendor's own tooling, and the two are usually sequenced deliberately — firmware first, then the hypervisor build that supports it, and vice versa depending on the vendor's guidance.

Do I need maintenance mode for a VIB-only install? You need no VMs running for any change that affects the storage or network stack, and a reboot is normally required. Treat every update as needing maintenance mode; the cost is a few minutes and the alternative is much worse.

That’s it, you have now updated your ESXi manually.