Problem
If you want to update an ESXi host (or you have upgraded the VMware vSphere appliance and try to enable HA on some hosts), sometimes it may be the case that it fails (most likely when you download the update either from VMware via esxcli command and a https source, or local download from the vCenter – instead of having the update on a datastore and pointing esxcli to the datastore). If you investigate this (in the case of failure to enable HA you may not have a look at esxupdate.log, but if you just updated you vCenter appliance and the hosts are still on the old version, just go there and have a look), you may stumble on some VMware knowledge base article which tells that this may be a disk space issue on the ESXi host. If you then have a look at the host, you see plenty of free space.
Reason
You can not see this issue after it has failed, it is only observable during the update process. The reason for this is, that the update process is creating a ramdisk where it tries to store the update temporary (at least if the hypervisor is not installed on something which is detected as a real disk – if you have it installed on a SD card which is detected by the ESXi kernel on a USB connection, then it is not a real disk in this case; the same is true if it is installed on a SSD behind an USB connection, I haven’t found a way to convince/force the installer or the hypervisor after the installation to assume it is a SSD or at least a real disk were it does not need to care about wear-leveling like on a SD card, feel free to add a comment to point me to a howto). This ramdisk is then too small and the update fails.
Solution
Put the update on a datastore and run the update via the esxcli command. If you use the remote source feature of esxcli, you will find the download URL in esxupdate.log. In case the update comes from the vCenter, you can at least find the VIP name in the esxupdate.log and you can use the “find” command to search it in the vCenter shell and then scp it to a (shared) datastore on a/the host.
