Patch a cluster as a sequence of controlled host changes. First prove that workloads can leave one host, then update that host and verify its storage, networking and applications before proceeding. A compliant image is a software-state result, not proof of a healthy service.
This guide assumes an existing image-managed vSphere 8 lab cluster, compatible licensed features and working shared storage. It does not convert a baseline-managed cluster, upgrade a whole major release or supply an emergency bootbank rollback recipe. No host was remediated for this draft.
1. Define the maintenance envelope
Choose the exact target ESXi build and record why it is needed: a supported security update, driver correction or approved platform lifecycle. Include vCenter, backup, monitoring, storage and networking integrations in the compatibility review. The newest available image is not automatically compatible with every installed component.
Prepare a host matrix containing model, CPU, boot media, firmware, storage controller, NICs, installed drivers and vendor add-ons. Record current and proposed versions. Keep vendor release notes and hardware compatibility evidence with the change record.
Calculate surviving capacity after one host is evacuated, including reservations and affinity constraints. If vSAN is present, storage policy, resync demand and maintenance data movement impose additional limits. Do not assume that enough free CPU implies enough capacity to maintain data protection.
2. Establish recovery access and a change boundary
Confirm independent hardware-console access, approved host recovery media and current configuration recovery material. Make sure these remain reachable when vCenter or a host network is unavailable. Assign an operator who can stop the wave.
Record the workloads and physical dependencies affected by the pilot host. Define stop conditions before remediation: failed evacuation, new path loss, unresolved storage-health degradation, application errors, unexpected driver state or a materially worse baseline.
Do not run another infrastructure change during the pilot. A simultaneous switch firmware update makes it difficult to determine which change introduced a fault.
3. Prepare the desired image
In Lifecycle Manager, inspect the depot and the cluster's existing desired image. If the site uses an approved offline process, obtain the entitled bundle from the official source, verify its integrity through that distribution process and import it into the depot.
Open the cluster's Updates view, inspect Host > Image and edit the intended desired image. Review the ESXi base image, vendor add-on and any additional components. Save only after the full combination matches the compatibility decision. Broadcom's offline/image workflow: https://knowledge.broadcom.com/external/article/453081/manual-or-offline-esxi-upgrades-using-vs.html
Changing the desired image does not immediately prove hosts have changed. Preserve the prior image description and export or record its exact component versions. Treat the desired state and the installed state as separate evidence.
4. Resolve pre-checks by cause
Run image validation, hardware compatibility assessment, compliance and remediation pre-checks for the selected lab scope. Read the detailed host findings, not only the cluster's headline status.
| Finding | Required investigation |
|---|---|
| A host has a newer component than the image | Resolve the image/component relationship with the vendor |
| Firmware cannot be assessed automatically | Obtain manual evidence for the exact hardware/driver pair |
| A VM cannot evacuate | Device constraints, affinity, datastore/network access or spare capacity |
| The host contains vCenter and automatic movement is unavailable | Explicitly plan and verify vCenter placement |
| vSAN health or evacuation capacity is insufficient | Restore protection/headroom before maintenance |
Lifecycle Manager does not perform automatic component downgrades to satisfy an older image. Do not remove an unknown VIB simply because a pre-check offers a removal path. Component-version pre-check behaviour: https://knowledge.broadcom.com/external/article/426960/precheck-fails-for-imagebased-remediatio.html
Some deployments lack a Hardware Support Manager and therefore cannot automatically verify firmware. That is missing evidence, not proof of incompatibility or permission to disable a blocking check across the estate. Firmware-check limitation: https://knowledge.broadcom.com/external/article/412988/error-the-image-has-hardware-compatibili.html
5. Keep the control plane available
Identify which host currently runs the vCenter appliance. A pre-check can require intervention when that host needs maintenance and DRS is disabled. Broadcom documents this vCenter placement dependency: https://knowledge.broadcom.com/external/article/417492/vlcm-precheck-shows-may-not-remediate-st.html.
For the lab, move vCenter through the approved migration workflow to a healthy host outside the first remediation target and verify access afterwards. Do not enable cluster-wide automation solely to clear one warning unless that separate policy change has been reviewed.
Check any other recovery dependencies: DNS, directory services, backup management and the operator's jump host. Evacuating them all onto the next host to be patched can recreate the same problem.
6. Remediate a single pilot host
Select the reviewed pilot scope in Lifecycle Manager, confirm the exact target image and review remediation settings. Ensure the selected scope is one host. If the installed workflow cannot safely limit that scope, stop and resolve the maintenance plan before submission.
Allow the supported workflow to evacuate workloads, enter maintenance, apply the image and perform required restarts. Do not force past evacuation errors or interrupt an active firmware/storage operation. Track the job through the normal task system; retain its completion or error record.
A host returning Connected is the start of acceptance. Confirm the installed build and components, physical NIC/link state, VMkernel services, datastore/path accessibility, time/DNS and cluster health. For vSAN, verify object compliance and resync state before restoring normal placement.
7. Run application acceptance and continue deliberately
Place a disposable workload on the patched host. Run its recorded application transaction and verify a correct result. Test migration to and from another healthy host, then inspect the same CPU, storage and network measurements used before the change.
Keep workload, dataset and concurrency comparable. Record a suitable observation interval rather than claiming success from one login. Investigate new alarms and errors even if an average performance chart looks unchanged.
Only begin the next host when the pilot passes and the cluster has regained the required protection and maintenance headroom. Recalculate surviving capacity after any incident or unexpected host unavailability. The original plan does not remain valid automatically after the environment changes.
Failure handling and rollback
If the pilot fails, stop the wave and preserve host tasks, logs and component details. Keep workloads on known-good capacity where possible. Do not repeatedly retry a failed remediation without resolving its cause.
Restoring the old desired-image description does not necessarily downgrade installed components. Host rollback depends on the supported update path, retained boot state, firmware and configuration compatibility. Prepare that recovery procedure with the platform/hardware vendor before the maintenance window; this draft does not provide a generic rollback keystroke or forced reinstall.
Acceptance and limits
Close the wave only when every intended host has the reviewed installed state, application and migration checks pass, protection is healthy and the evidence record shows no unresolved regression. Image compliance and service acceptance should be recorded separately.
An isolated rehearsal validates its hardware/software combination. It does not establish compatibility for another server model, HBA firmware or vSAN architecture. Production scheduling and execution remain separate authorised work.
Related topics: cluster commissioning, vSAN policy headroom and vCenter recovery.
Learning notes
- A desired image and an installed host image are different states.
- Missing compatibility evidence must be resolved before remediation.
- A successful first host is the gate for the next host, not permission for every host at once.
Sources and review status
See the source ledger, author self-check and series index. Independent review and lab validation remain pending.