Manually Patching an ESXi Host from the CLI

Manually patching standalone ESXi hosts without access to vCenter or Update Manager using offline bundles and the CLI.

There are many different reasons you may want to patch your ESXi host. VMware regularly releases bug fixes and security patches, or perhaps you need a newer build for compatibility with another application or third-party tool. In my situation, the ESXi 6.7 U1 ESXi hosts (build 10302608) are not compatible with NSX-T 2.4.0, so I need to get them patched to at least 6.7 EP06 (build 11675023).

hostupgcli-1

Before you get started, you’ll want to figure out which patch release you want to update to. There is quite often some confusion surrounding the naming of VMware patch releases. In some cases, a build number is referenced, for example, 10302608. In other cases, a friendly name is referenced – something like 6.7 EP06 or 6.5 P03. The EP in the name denotes an ‘Express Patch’ with a limited number of fixes released outside of the regular patch cadence, where as a ‘P’ release is a standard patch. In addition to this, major update releases are referred to as ‘U’, for example, 6.7 U1. And to make things more confusing, a special ‘Release Name’ is quite often referenced in security bulletins and other documents. Release names generally contain the release date in them. For example, ESXi670-201903001 for ESXi 6.7 EP07.

The best place to start is VMware KB 1014508, which provides links to numerous KB articles that can be used for cross referencing build numbers with friendly versions names. The KB we’re interested in for ESXi is KB 2143832.

Once you’ve been able to get the build number for your desired patch, you can visit the VMware Patch Tool site. In my case, I went ahead and downloaded ESXi670-201901001.zip. This ZIP file – and all ESXi patches – are what is referred to as an “offline bundle”. Offline bundles are collections of VIBs bundled with metadata describing their contents. You don’t need to extract the ZIP file as part of the upgrade process. The ESXi host will process the ZIP file automatically to pull out the modules and metadata.

hostupgcli-2

In the ZIP file, the VIBs are contained in the vib20 directory. The other files contain metadata, including vendor related information.

The first thing we’ll need to do is upload the file over to a location that can be accessed by the ESXi hosts. Quite often, WinSCP is used for this process, but you can also use the datastore browser to put it in a shared datastore that can be accessed by all your hosts.

hostupgcli-3

I uploaded it to the root of the datastore called shared-hdd0. Before you begin, it would be a good idea to put the host into Maintenance Mode.

I then opened an SSH session and logged into esx-e1 as root:

[root@esx-e1:~] ls /vmfs/volumes/shared-hdd0/*.zip
/vmfs/volumes/shared-hdd0/ESXi670-201901001.zip

Make a note of the full path. Notice that the datastore name is used after /vmfs/volumes.

The command to initiate the update is esxcli software vib update, specifying an offline depot using the -d or –depot flags. The syntax I used is listed below:

[root@esx-e1:~] esxcli software vib update --depot=/vmfs/volumes/shared-hdd0/ESXi670-201901001.zip

My first attempt actually failed with the following error:

 [StatelessError]

 The transaction is not supported: VIB VMware_bootbank_lsu-lsi-lsi-msgpt3-plugin_1.0.0-9vmw.670.1.39.11675023 cannot be live installed. VIB VMware_bootbank_esx-base_6.7.0-1.39.11675023 cannot be live installed. VIB VMware_bootbank_esx-update_6.7.0-1.39.11675023 cannot be live installed. VIB VMware_bootbank_vsan_6.7.0-1.39.11399593 cannot be live installed. VIB VMware_bootbank_lsu-lsi-lsi-msgpt3-plugin_1.0.0-8vmw.670.0.0.8169922 cannot be removed live. VIB VMware_bootbank_esx-update_6.7.0-1.28.10302608 cannot be removed live. VIB VMware_bootbank_esx-base_6.7.0-1.28.10302608 cannot be removed live. VIB VMware_bootbank_vsan_6.7.0-1.28.10290435 cannot be removed live.

 Please refer to the log file for more details.

This is a common issue where certain kernel modules fail to unload. If you run into this, the workaround is quite simple. Make sure the host is in maintenance mode, reboot it and then run the command again. In my case it was successful after doing this:

[root@esx-e1:~] esxcli software vib update --depot=/vmfs/volumes/shared-hdd0/ESXi670-201901001.zip

Installation Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: VMware_bootbank_esx-base_6.7.0-1.39.11675023, VMware_bootbank_esx-update_6.7.0-1.39.11675023, VMware_bootbank_lsu-lsi-lsi-msgpt3-plugin_1.0.0-9vmw.670.1.39.11675023, VMware_bootbank_vsan_6.7.0-1.39.11399593, VMware_bootbank_vsanhealth_6.7.0-1.39.11399595
   VIBs Removed: VMware_bootbank_esx-base_6.7.0-1.28.10302608, VMware_bootbank_esx-update_6.7.0-1.28.10302608, VMware_bootbank_lsu-lsi-lsi-msgpt3-plugin_1.0.0-8vmw.670.0.0.8169922, VMware_bootbank_vsan_6.7.0-1.28.10290435, VMware_bootbank_vsanhealth_6.7.0-1.28.10290721
   VIBs Skipped: VMW_bootbank_ata-libata-92_3.00.9.2-16vmw.670.0.0.8169922,
<snip>

Once the update is finished, it’ll be necessary to reboot the host.

hostupgcli-4

That’s it! Not difficult at all, and can be useful for standalone ESXi hosts that don’t have access to vCenter and Update Manager.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s