A Field Guide to ESXi 8 Upgrades: The Checks Nobody Tells You About

I’ve now taken four separate environments through major ESXi upgrades, and the pattern holds every time: the upgrade itself is uneventful, and every problem traces back to something that was checkable in advance. This is the pre-flight list I actually use, including the checks that aren’t in the official docs.

Before anything: know your rollback story

Write down — before the window opens — the answer to: “It’s 01:30, the host won’t boot after the upgrade. What now?” Your options depend on decisions made long before:

• Boot from local disk? ESXi keeps the previous bootbank. Shift+R at boot rolls back.
• Boot from SD card/USB? You have my sympathy, and you should have a replacement plan — ESXi 8 formally deprecates these. Treat this upgrade as the forcing function.
• Stateless / Auto Deploy? Your rollback is the image profile, which is the good news. The bad news is everything else about Auto Deploy.

The hardware compatibility check that actually matters

Everyone runs the HCL check against the server model. The failures come from what’s in the server. Validate the specific combination of NIC/HBA firmware and the driver that ships in your target image:

# Current driver and firmware per NIC
esxcli network nic list
esxcli network nic get -n vmnic0 | grep -A2 'Driver Info'

# Storage adapters — note driver names for HCL lookup
esxcli storage core adapter list

Cross-reference against the Broadcom Compatibility Guide for the target release, not the current one. The classic failure: an ancient qfle3 or nmlx4 driver that works fine on 7.x and is simply absent from the 8.x image.

Boot device health — the silent killer

A worn-out boot device survives day-to-day operation and then dies during the intensive write phase of an upgrade. Two minutes of checking saves a very bad night:

# Which device are we booting from?
ls -l /bootbank
vmkfstools -P /bootbank | head -3

# For local SSDs/M.2 — check wear indicators
esxcli storage core device smart get -d <device-id>

Anything with reallocated sector counts climbing, or SD/USB boot of any kind: replace the boot device first, upgrade second.

Building the image: cluster image, not baselines

If you’re still on baseline-based updates, ESXi 8 is the moment to switch to cluster images (the vLCM “single image” model). One image per cluster, composed of:

1. Base ESXi version — the Broadcom-released depot.
2. Vendor addon — Dell/HPE/Lenovo bundle matching your firmware baseline.
3. Firmware and drivers addon — if you have the hardware support manager plugin.
4. Independent components — NSX kernel modules, backup agents, and so on.

The discipline this buys you: hosts cannot drift individually, because compliance is evaluated against the one image. Our config drift incidents went to zero after the migration — not “near zero”, zero.

The remediation loop that respects production

For a 16-host cluster, serial remediation with these settings has never let me down:

# PowerCLI — kick off remediation with explicit, conservative options
$cluster = Get-Cluster 'PROD-A'
$spec = @{
  Cluster                  = $cluster
  AcceptEULA               = $true
  HostRemediationMode      = 'Sequential'
  EnableQuickBoot          = $true      # halves reboot time on supported hardware
  RetryDelaySeconds        = 300
  MaxRetries               = 2
}
# (Illustrative — actual cmdlet surface varies by vLCM API version)

After each host, before the next

Automate a smoke test between hosts. Mine checks, in order:

• Host reconnects to vCenter and exits maintenance mode cleanly
• All expected vmnics are up with correct link speed
• Storage paths: count matches pre-upgrade snapshot (esxcli storage core path list)
• vSAN health (if applicable) is green and resync is at zero
• A canary VM vMotions onto the host and back off

Only when the canary passes does the loop continue. Sequential remediation with a gate means an upgrade problem costs you one host, not a cluster.

The unglamorous summary

Upgrades don’t reward cleverness, they reward preparation. Check the drivers against the target image, check the boot device, know the rollback, gate the loop. Every ESXi upgrade that went badly for me skipped one of those four — every single one.