vCenter 8 and ESXi 8 — Preupgrade Issues to be fixed

Follow-up to VMware. Upgrading vCenter and ESXi is rarely “click Next until done.” The preflight(pre-upgrade) wizard and esxcli output tell you most of what will bite you — if you read them before the change window.

Page: VMware. Physical layer: Physical Hardware.

vCenter 7 → 8: errors that stop the upgrade

These are from real preflight runs. The categories repeat across environments.

Host profiles older than 6.7 (hard stop)

vCenter 8 rejects source environments with host profile versions below 6.7. Preflight lists each non-compliant profile by name — cluster baseline profiles, one-off “reset root password” profiles, lab templates, all of it.

Fix before vCenter: upgrade or recreate those profiles to 6.7+ (VMware KB 52932). Do not assume “we barely use host profiles” — if one stale profile exists, the vCenter upgrade stops.

Host profile work belongs before vCenter and before you finish upgrading ESXi hosts still on very old builds.

Extensions that may not survive the move

Aria Operations / legacy vROps plugins often show as extensions that cannot be upgraded automatically or may not work on the new vCenter. Plan to verify compatibility, re-register after cutover, and if monitoring is managed by different team have them notified — not after having false alerts in next morning.

Lifecycle Manager baggage that will not copy

Guest OS patch baselines, old host upgrade baselines, and ESXi 6.5-and-lower patch content do not migrate to the new Lifecycle Manager. That is not a bug — rebuild baselines on the new vCenter rather than hunting for “missing” files after upgrade.

DRS mode during host work

Preflight warns when clusters are Fully Automated DRS while hosts tied to the upgrade are still in play. For the duration of host patching or vCenter migration windows, I move affected clusters to manual or partially automated DRS so VMs are not relocated mid-maintenance.

vCenter appliance sizing and NICs

Common warnings that are easy to dismiss:

Source vCenter has more vCPUs than the default target appliance — resize after stage 2 if you need parity.
Multiple NICs on the source — only active adapters come across cleanly; secondary NICs may need manual re-add post-upgrade.

When stage 1 dies on database export

I have hit “Internal error occurs during Export of VMware vCenter Server Database” mid-upgrade. That is support-bundle territory — not something to retry blindly three times in the same window. Take a snapshot or backup of the source appliance before you start, and have a rollback plan ready.

ESXi 8 on UCS and rack servers: bundles beat generic zip

On Cisco UCS hosts I use the vendor-customized ESXi depot (Cisco UCS add-on profile), not the generic VMware zip alone. On Dell rack servers, the Dell customized bundle. Standard profiles often fail with driver/VIB dependency errors on hardware that has been running fine for years.

Pattern on the host

Enter maintenance mode first. Copy the bundle to local VMFS (not HTTP — offline install rejects remote URIs):

esxcli system maintenanceMode set --enable true

# List profiles in the depot
esxcli software sources profile list -d /vmfs/volumes/<DATASTORE>/ISO/<vendor-or-standard-depot.zip>

# Apply the matching profile name from that list
esxcli software profile update \
  -d /vmfs/volumes/<DATASTORE>/ISO/<vendor-or-standard-depot.zip> \
  -p <Profile-Name-From-List> \
  --no-hardware-warning

--no-hardware-warning is a conscious choice — only after the profile matches your hardware support matrix, not because the patch is late.

If standard depot fails with dependency errors on UCS or blade hardware, switch to the OEM/custom bundle before chasing individual VIBs.

ESXi 7.x patch lesson that still applies at 8

On a 7.0.2 → 7.0.3 patch, DependencyError from orphaned QLogic FC VIBs (qedi / qedf) still installed while the active HBAs were Cisco VIC (nfnic) blocked the depot. The adapters in use did not need those VIBs — removing the stale packages and rebooting cleared it:

esxcli software vib list | grep -E 'qedi|qedf'
esxcli storage core adapter list   # confirm nothing active uses them
esxcli software vib remove -n qedf
esxcli software vib remove -n qedi
reboot
# then retry profile update with the correct bundle

Lesson: installed ≠ in use. Before ESXi 8, inventory VIBs against actual vmhba drivers, not against what was true when the host was built.

Offline bundle must be local

esxcli software vib install -d http://... fails with “Only server local file path is supported.” Copy the depot to VMFS (wget to a datastore path works), then point esxcli at the local zip.

Pacing host upgrades in big clusters

For multi-host UCS clusters I batch 4–8 hosts per maintenance window, maintenance mode → evacuate → patch → reboot → exit MM, rather than racing the whole cluster in one night. On a large migration program we moved VMs in three nightly waves (~50–70 VMs per night) ahead of host work so evacuate did not turn into surprise Storage vMotion during business hours.

Preflight also threw “Compatibility check took too long” on a busy vCenter — check vCenter logs, reduce concurrent tasks, retry off-peak. Treat timeout as a signal, not noise.

Order I actually run

Step	What
1	Interop matrix: vCenter, ESXi, UCS firmware bundle
2	Host profiles → 6.7+
3	vCenter upgrade (with extension/monitoring plan)
4	Rebuild Lifecycle Manager baselines on new vCenter
5	ESXi hosts: vendor bundle, MM, evac, patch, verify
6	Storage/cluster validation if VMs use Veritas or RDM

That last row matters if you are also moving SAN paths — see Veritas SAN migration. ESXi maintenance and storage cutover in the same week without coordination is how plexes go TEMPRMSD.

Quick reference

Preflight / error	First move
Host profile version	Upgrade profiles to 6.7+ (KB 52932)
Extension warning	Confirm Aria/vROps compatibility; plan re-register
DRS fully automated	Manual/partial for upgrade window
ESXi dependency error	Vendor bundle; check orphan VIBs vs active HBAs
Remote depot URL	Copy zip to VMFS first
vCenter DB export fail	Stop; support bundle; do not blind retry