On a supported server, patching ESXi is routine. On a custom PC, every update is a small bet: a new build, a refreshed driver set, and the same unsupported network card underneath it all. This page is about placing that bet safely — or deciding, on a given evening, not to place it at all.
The fear is specific and justified: the update installs, the host reboots, and the management page never comes back — because the new build's driver set no longer matches some piece of your consumer hardware. It happens rarely, mostly on big version jumps rather than small patches, but "rarely" is cold comfort at midnight. The professional answer is not to avoid updates; unpatched hypervisors collect real security fixes. The answer is to make every update reversible, and to prove the host healthy afterwards in a fixed order.
👆 Updates on unsupported hardware are safe exactly to the extent that they are reversible. Every line here buys reversibility (illustration).
ESXi can be updated two official ways. The friendly route for a whitebox is booting the newer installer ISO and choosing Upgrade instead of Install — it keeps your configuration, datastores and VMs, and it shows you the hardware detection screens again before committing. The second route patches from the command line, applying a downloaded offline depot with esxcli software profile update — powerful, and the usual choice on remote hosts. Whichever you pick, the source is always VMware's portal; never install a depot or ISO that a forum or file host handed you.
Before anything else: export the VMs you care about (an OVF or OVA export from the Host Client), or shut them down and copy their folders to another machine or disk. Note the current build number — visible on the Host Client's summary page — and keep the installer ISO of the build you are running today. With those three things, every failure mode has a way back: roll back the host, or rebuild the host and re-import the VMs. Without them, you are not updating; you are gambling.
Between major versions, VMware refreshes the driver set and retires hardware support. On a supported server nobody notices. On a whitebox, a card or controller that worked can come back unrecognised after a version jump — and a host whose management NIC has vanished looks exactly like a dead host. Small patches within one version are far lower risk than version jumps. That is the graded reality: patch within your version promptly; treat a version jump as a project with a free evening attached.
Do not declare victory because the login page loads. Work a short proof, in order: confirm the new build number in the Host Client; check that every datastore is present and healthy; start one unimportant VM and confirm it networks; then start the rest. Glance at the host's event log for storage or device complaints. Ten minutes of proof is what separates an updated host from a host you merely hope is updated.
ESXi quietly keeps the previous build as an alternate boot image. If a freshly updated host misbehaves, restart it and hold Shift+R when the boot loader offers recovery options — the host rolls back to the earlier build with your configuration intact. Know also what rollback is not: it is a short bridge, not a lifestyle. Roll back, breathe, work out which driver or device the new build objected to, and only then decide whether to fix forward or stay put deliberately.
The video shows the end state of a happy whitebox host. This guide is how you keep yours that way across every update.
▶️ Watch Full VideoTreat it as a project, not a patch. Driver support changes the most between major versions, and many whitebox owners honestly prefer a fresh install of the new version — with VMs exported first and re-imported after — over an in-place jump. Either way, the backup checklist on this page comes first.
Almost certainly not — the classic cause is a NIC the new build no longer drives. Roll back with Shift+R at boot to restore the previous build and its working drivers, then decide with a clear head whether to change hardware or stay on the older build.
They keep running as they were. Two optional refinements arrive over time: updating VMware Tools inside the guests, and raising the virtual hardware version for newer features. Both are per-VM choices you can make slowly — neither is forced by a host patch.