By William Lam, Sr. Technical Marketing Engineer

As you know, when it comes to automating patch management for your vSphere infrastructure, we highly recommend leveraging our vSphere Update Manager (VUM) which is part of the vSphere vCenter Suite to help simplify the update process. Though not all environments have the luxury of running vCenter Server to manage their ESX(i) hosts. An example of this could be 1-2 hosts running at a ROBO (remote office/branch office) site or single test/dev host in a home or office lab where VUM is not available.

However, it is still possible to patch/upgrade your ESX(i) host using the command-line without the need of VUM, but you will have to manually identify the patch dependencies and ensure host compliance.

Depending on the version of ESX or ESXi you are running, you may have several options that could include local and/or remote command-line utilities that are available in following four forms:

• ESX Service Console
  • esxupdate – Local utility found on classic ESX hosts to manage/install patches
• ESXi Shell
  • ESXCLI – Local utility found on ESXi 5.0 hosts that can be used manage/install patches
• vCLI (Windows/Linux or use vMA)
  • vihostupdate35 – Remote utility to manage/install patches for ESXi 3.5
  • vihostupdate – Remote utility to manage/install patches for ESX(i) 4.0 & 4.1
  • ESXCLI – Remote utility to manage/install patches for ESXi 5.0 (patch capability introduced in vSphere 5 for ESXi 5.0 hosts only)
• PowerCLI(Windows)
  • InstallVMHostPatch – Remote utility using PowerCLI to manage/install patches for ESX(i) 4.0 and 4.1

Note: If you are using vSphere Hypervisor (Free ESXi), you will not be able to leverage any of the the remote CLI’s but you can still use the local CLI.

Here is a table summarizing all available command-line options based on the version of ESX(i) you are running:

Note: When you download patches from VMware, there is an associated VMware KB article and it provides a link to the patch management documentation. You should always refer to that for more details and information for different methods of applying a patch.

Here is an example of using esxupdate on a classic ESX host. The patch bundle needs to be uploaded to ESX host using scp or winSCP and then specifying the full path on the command-line:

$ esxupdate −−bundle=ESX400-200907001.zip update

Here is an example of using the remote vihostupdate utility for an ESXi host, you will need to specify the ESXi host using the −−server parameter and −−username/−−password for remote authenication. You may choose to leave off −−password and you will be prompted to enter your credentials. The patch bundle does not need to be uploaded to ESXi host, it can reside on the system that is running the vihostupdate command. During the execution, the patch bundle will automatically be transfered to the host:

$ vihostupdate −−server [ESXI-FQDN] −−username [USERNAME] −−bundle=ESXi410-201011001.zip −−install

Here is an example of using the local esxcli utility for an ESXi 5.0 host. The patch bundle needs to be uploaded to ESXi host using scp or winSCP and then specifying the full path on the command-line:

$ esxcli software vib update −−depot=/vmfs/volumes/datastore1/ESXi500-201112001.zip

Here is an example of using the remote esxcli utility for an ESXi 5 host, you will need to specify the ESXi host using the −−server parameter and −−username/−−password for remote authenication. You may choose to leave off −−password and you will be prompted to enter your credentials. The patch bundle needs to be uploaded to ESXi host using scp/winSCP or vCLI’s vifs utility and then specifying the full path on the command-line:

$ vifs −−server [ESXI-FQDN] −−username [USERNAME] -p ESXi500-201112001.zip “[datastore1] ESXi500-201112001.zip”
$ esxcli −−server [ESXI-FQDN] −−username [USERNAME] software vib update −−depot=/vmfs/volumes/datastore1/ESXi500-201112001.zip

Note: In ESXi 5, −−depot only supports local server path or remote URL. The latter is to help centralize the location of your patches and help reduce manual transfer. This is why you need to transfer the patch to host if you do not have a patch depot.

Here is an example of using Install-VMHostPatch utility for an ESXi host:

Get-VMHost ESXI-FQDN | Set-VMHost -State Maintenance
$DS = Get-VMHost ESXI-FQDN | Get-Datastore datastore1
Copy-DatastoreItem C:\tmp\ESXi500-201112001\ $DS.DatastoreBrowserPath -Recurse
Get-VMHost ESX-FQDN | Install-VMHostPatch -Hostpath “/vmfs/volumes/datastore1/ESXi500-201112001/metadata.zip”

Note: The Install-VMHostPatch cmdlet does have a -LocalPath parameter for you to specify a local path to the patch. For larger files it is recommended you use the Copy-Datastore cmdlet to upload the file to a datastore on the host and then the -HostPath parameter as can be seen in the example above.

As you can see over the releases, we have had several methods of patching a host using the command-line both locally/remotely and it may not always be intuitive. When we converged to only ESXi with the release of vSphere 5.0, you will see that patching from the command-line has also converged to a single command-line utility using ESXCLI and a common patch format called a VIB. ESXCLI was first introduced in vSphere 4.0 and it had some limited capabilities. With vSphere 5.0, it has been significantly enhanced and now supports patching as one of it’s many capabilities. The syntax and expected output is exactly the same if you execute ESXCLI locally or remotely on an ESXi host with the exception of the remote authentication that is required for a remote execution. This should provide for a better user experience and consistency going forward.

An alternative method to patching from the command-line if you do not have VUM is using VMware Go, which is an online service (SaaS) provided by VMware. VMware Go can help manage your ESXi host but it also provides a patching capability similar to that of VUM.

Get notification of new blog postings and more by following lamw on Twitter:  @lamw