Upgrading ESX in VCF 9.1.1 from VCF Operations: “There are no images available”
Another field report from a VCF 9.1 → 9.1.1 upgrade: why the ESX step of the Configure Upgrade wizard asks for an image maybe didn’t configured yet, how to create and import it, what the prechecks said.
Abstract
- VCF Operations does not build the ESX image for you. It consumes a vSphere Lifecycle Manager (vLCM) image that you create in vCenter and then import under Build → Lifecycle → <VCF instance> → Image Management.
- If no image matches the target version, the wizard shows “There are no images available that match the required target version to initiate the vLCM upgrade” and Next stays greyed out.
- ESX comes after SDDC Manager, NSX and vCenter: they must already be on 9.1.1 before you start the ESX step.
Prerequisites:
The ESX upgrade comes after SDDC Manager, NSX and vCenter in the management domain sequence. Before you start, make sure that:
- SDDC Manager, NSX Manager and vCenter are on 9.1.1. In our environment they were: the Import Image dialog later shows vCenter “9.1.1.0”, and the upgrade plan lists SDDC Manager, NSX, vCenter and ESX as its steps.
- VCF Operations and the License Servers are patched first, as required by the 9.1.1 release notes for ESX patching.
- The cluster uses vLCM images, not legacy baselines.
- Backups are in place (SDDC Manager and NSX, with a fresh run right before you begin – see the previous article), and the vSAN cluster is healthy.
The Component Versions view of the management domain shows exactly what is about to happen: four hosts on 9.1.0.0200.25557999 with the target 9.1.1.0.25714478 (“Version Drift”).
The Problem: There are no images available
In VCF Operations go to Build → Lifecycle → VCF Instances → <instance> → <management domain> → Upgrades, plan the ESX step and click Configure. In step 3 of the wizard, “Assign Images to Clusters”, the cluster is listed with Target ESXi Version, Vendor Addon, HSP and Image all set to “None”, and a warning appears:
The reason is simple: the image catalog of VCF Operations only contained the image of the existing version, Management-Domain-ESXi-Personality (ESXi 9.1.0.0200.25557999). Nothing in the catalog matched 9.1.1.0.25714478.
The Fix: Create the Image in vCenter and import it
Open the vSphere Client, select the cluster, and go to Updates → Hosts → Image → Edit. Select the target ESXi version (here 9.1.1.0.25714478). Add a Vendor Addon or a Firmware and Drivers Addon only if you use them – I did not, so both stay empty. Save the image.
Is the 9.1.1 version not offered in the dropdown? Then vCenter does not have the 9.1.1 content in its Lifecycle Manager depot yet. With internet access, sync the updates in the vSphere Client. In an environment without internet access, import the ESX offline bundle (ZIP) into the vCenter Lifecycle Manager first – the same restriction that blocked the Fleet Lifecycle binaries earlier in this upgrade.
Back in VCF Operations, open Image Management and click Import Image. Choose “Import from a vCenter”, select the vCenter, click Refresh, select the new image and click Import. (“Import from a file” is the alternative: upload the JSON, ZIP and ISO files you exported from the vSphere Client.) The dialog also has a “Go to Image Library” link that takes you straight to vCenter.
The list is empty in this screenshot only because the image had already been imported; on a first run, the image you created in vCenter is listed here. After the import, the catalog contains a second entry for ESXi 9.1.1.0.25714478. In our case it shows up as autogen-software-spec-1, last modified on the day of the upgrade. The name is not important – the ESXi version is.
Now restart the Configure Upgrade wizard. In “Assign Images to Clusters” click Assign Image and pick the imported image. The warning is replaced by a green confirmation, the cluster now shows target version 9.1.1.0.25714478, and Next is enabled.
The next step contains the remediation options. This is what I used for the 4-node management cluster:
| Option | Setting and meaning |
| Enable sequential cluster upgrade | Disabled – only relevant when several clusters are upgraded in one batch. |
| Enable Quick Boot | Enabled – skips the full hardware restart where the host supports it, which shortens each reboot. |
| VM power state | Do not change power state. |
| Migrate powered off and suspended VMs | Enabled – such VMs are moved to other hosts if a host has to enter maintenance mode. |
| Prevent remediation if hardware compatibility issues are found | Disabled – see section 5 for why this matters here. |
| Retry policy | Enabled: 3 retries, 5 minutes apart. |
| Enable Live Patch | Enabled, mode “Auto” – use Live Patch when possible, otherwise maintenance mode and reboot. “Enforce” would stop as soon as one host needs a reboot. |
The Review page summarizes cluster, hosts (4 / 4), target image and all options. Click Finish to store the plan.
After Finish, the upgrade sequence shows “VMware ESX 9.1.1.0 Upgrade – Upgrade batch #1”. Run the prechecks and wait for them to finish before you click Upgrade Now or Schedule.
Our result: 0 errors, 18 warnings, 44 passed, 0 silenced. No errors means nothing blocks the upgrade. I reviewed the warnings (View Details, filter “Warnings”). Most of them were harmless findings; the one that deserves a closer look is the hardware compatibility check.
Running the Upgrade
With the image assigned, the prechecks free of errors and the compatibility warning understood, the batch offers Upgrade Now and Schedule. I clicked Upgrade Now.
The Upgrades tab switches to a status view: “VMware Software Upgrade 9.1.1.0”, “Upgrading Host Cluster”, and a step list for the cluster: Start, Precheck, Upload Personality Bundle, Create Draft, Update Draft, Set Desired State, Disable DRS Rules, Remediate, Enable DRS Rules. The actual host-by-host work happens in the Remediate step, which is why it stays on the spinner the longest. DRS rules are switched off for the duration of the remediation and enabled again afterwards, as the step names say.
VCF Operations only shows the summary. If you want to see what really happens, open the cluster in the vSphere Client and watch Recent Tasks. Per host, vLCM runs the same pattern: vSAN resource check → host decommission resource check → Enter maintenance mode, during which the VMs are migrated off the host (“Migrate virtual machine” tasks, with the maintenance-mode task waiting for them), then the remediation and the host reboot.
A few minutes later the next stage is visible: the host is in maintenance mode, “Initiate host reboot” has completed for it, and DRS is migrating further VMs (including the vCenter appliance itself) to hosts that are not being patched.
What about the vSAN alarms? During the remediation the cluster summary shows alarms such as the vSAN data alarm “vSAN object” and the vSAN cluster alarm “Disk format version”. Alarms of this kind are common while a vSAN host is in maintenance mode and objects temporarily have reduced redundancy. They are no reason to cancel a rolling upgrade, but you should check the vSAN health and make sure that no resync is running before the next host goes down. The “Disk format version” alarm typically refers to the on-disk format of the vSAN disks and is a separate follow-up item after the ESX upgrade, not a blocker for it.
After the remediation, the Component Versions view of the management domain shows the cluster On Target with ESX 9.1.1.0.25714478. SDDC Manager (9.1.1.0.25713928) and vCenter (9.1.1.0.25712839) are on target as well.
That’s it from this Blog post, if you have any questions please use the comment section below. 🙂