ESXi 6.7 to 8.0 Update - Fix Production Server Crash

Check the Hardware Compatibility First

ESXi 6.7 reached the end of general support on 15 October 2022, so the move is overdue — but 6.7 to 8.0 is a major-version upgrade, not a patch. Between the two versions VMware removed the VMKLinux driver model entirely (every device now needs a native driver) and retired a generation of CPUs, network adapters and storage controllers. A perfectly healthy 6.7 host can still be un-upgradable as it stands.

Before any window is booked, check the VMware Compatibility Guide for your exact server model, CPU family, network adapters and storage controller against ESXi 8.0, and update the server firmware (BIOS, storage controller, NICs) to the versions the vendor lists for 8.0. The installer's own pre-check also warns about deprecated devices — but finding out at the console at midnight is the wrong time. Check on paper first.

Back Up the Host Configuration and the VMs

Back up the host configuration from the host shell (enable SSH on the host first if it is off). The command returns a download link for the configuration bundle — open it and save the .tgz file somewhere that is not on this server:

vim-cmd hostsvc/firmware/backup_config

Then confirm the VM backups are current and that at least one restore has actually been tested. Half of all post-upgrade purple screens trace back to firmware the old hypervisor tolerated — but the crashes you cannot undo are the ones with no backup behind them.

Plan the Window and Keep the 8.0 Licence Key Ready

Pick a maintenance slot and announce it to the users — nobody should be mid-save when the host goes down. Write the sequence down with times, and set a hard rollback deadline: the point in the night after which you stop debugging and roll back (Step 7) instead of eating the whole window. Send a closing message when the work is done, so the next morning does not start with rumours.

Get the licence sorted before the window, not during it. Licence keys are tied to the major version — an 8.0 host will not accept a 6.7 key, and without one it runs in evaluation mode for 60 days. Under Broadcom, keys and downloads come from the Broadcom support portal against your entitlement, so arrange that access in advance.

Route A — Upgrade by Booting the 8.0 ISO

Tell the users, then put the host into maintenance mode — every VM shut down or migrated to another host. Never upgrade a host that is still running production VMs.

Boot the ESXi 8.0 installer from the ISO, select the disk that holds the existing installation, and choose Upgrade ESXi, preserve VMFS datastore. This is the route shown on most servers, and the one that handles a big version jump cleanly because the pre-checks appear on screen as it goes.

Route B — Upgrade from the Shell with esxcli

The depot route runs entirely from the host shell — no physical or virtual media — which makes it the practical choice for a remote host. The host still goes into maintenance mode first, exactly as in Route A. Allow the HTTP client through the host firewall:

esxcli network firewall ruleset set -e true -r httpClient

List the profiles available in VMware's online depot, and note the exact name of the 8.0 standard profile:

esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Then run the profile update against the depot, using that exact profile name, and reboot the host when it completes:

esxcli software profile update -d <depot-url> -p <exact-profile-name>

The same route works offline: copy the depot bundle ZIP to a datastore and point the -d value at that file instead. Note that profile update is the upgrade command — it keeps your existing configuration and third-party VIBs where they are compatible; do not substitute profile install, which replaces the image.

After the Reboot — Licence, Verify, Then Release

Once the host is back up on 8.0, apply your ESXi 8.0 licence key — the 6.7 key is not accepted, and without the new key the evaluation clock is ticking. Exit maintenance mode, then start one non-critical VM first and check its network, storage and console before starting the rest.

Work through the host itself next: the event log and hardware status for driver or sensor complaints, every datastore mounted, and the management network settings intact. Only then release the server back to the users, and send the closing message from Step 3.

The Crash Playbook — Purple Screen and the Shift+R Rollback

If the host purple-screens (PSOD) or will not boot usefully after the upgrade, work in this order. First, photograph the purple screen before touching anything. A PSOD is the VMkernel stopping deliberately because continuing would risk the VMs — and the screen is the diagnosis: the exception type and the module named on it point at the cause, with a driver module name indicating a hardware-support problem and a page fault pointing at memory or firmware.

Second, reboot once and watch. A single transient purple screen after a driver change is data; a repeating one is a verdict. The first suspects, in the upgrade's own order: an unsupported NIC or storage adapter, firmware older than the compatibility guide lists, or a memory error the old version never stressed.

Third, roll back. ESXi installs into two boot banks, and the upgrade leaves your previous 6.7 build intact in the alternate bank. Reboot the host and, at the boot prompt, press Shift + R and confirm — the host boots the previous 6.7 build, configuration included, exactly as you left it. If the rollback works, you have bought time: fix the compatibility cause in daylight and upgrade again in a new window.

vim-cmd hostsvc/firmware/restore_config <bundle-path>

That restore command is the second escape route — it puts the host configuration from the Step 2 bundle back onto a host of the same version and build, for the cases where one boot bank is not enough.