Deep Dive of the Day vSphere Lifecycle Manager images in VCF 9, and what composite images add
If you're bringing older clusters into VCF 9, the first thing to check is how their hosts are patched. Baselines, the old Update Manager model of stacking patches onto hosts, were deprecated in vSphere 8.0, gained a supported conversion path in VCF 5.2.2 and were removed in vSphere and VCF 9.0. As Dr Pranay Jha's workshop write-up puts it, this is a hard gate rather than advice: the VCF 9 installer's validation fails for a baseline-managed cluster. An image is declarative instead: one desired state per cluster, made of a base ESX version, an optional vendor add-on, optional firmware and drivers delivered through a hardware support manager (HSM), and any extra components, enforced on every host.
In VCF 9 the workflow is split between two places, per the TechDocs page on managing vLCM images for VCF. You build the image in the vSphere Client, then import it into the VCF instance through VCF Operations. Once imported, it's what you pick when you create a workload domain, add a cluster to a domain, or upgrade a domain. If your fleet runs with an offline depot or no depot at all, you need the VCF Download Tool to bring in current ESX component data before you can build images in the vSphere Client.
The newer piece is composite images, which deal with the classic problem of a cluster that grew across hardware generations. A composite image has one default image plus additional image definitions, up to four, and every definition shares the same base ESX version and the same solutions. What can differ per definition is the vendor add-on, the firmware and the components, and each definition can have its own HSM attached. Hosts are matched to a definition either by hand or automatically from their System BIOS details: vendor, model, OEM string and family. That means a cluster with two server vendors, or two generations from one vendor, no longer forces you into a lowest-common-denominator image.
For the conversion itself, Jha's sequence is sensible: check the hardware against the Broadcom Compatibility Guide (and confirm you have an HSM if firmware will be in the image), fix any existing baseline non-compliance first, back up vCenter and record each host's build, drivers and firmware, then switch the cluster to a single image seeded from an existing host. Run a compliance check as a dry run and read the drift report before remediating host by host. Switching the cluster's lifecycle model doesn't reboot hosts or move VMs; remediation does. He also calls it a one-way door, since there's no going back to baselines on 9.0.
The gotchas are mostly about timing. Do the conversion before you deploy or converge into VCF 9, not during it, and don't start with hosts that are already non-compliant, or the before-and-after comparison becomes guesswork. The base version being fixed across a composite image also means a mixed cluster still upgrades ESX as one, so check every hardware vendor's add-on is available for the target release before you plan the window. In a nested lab the same installer check applies, so convert your nested clusters to an image before you point the VCF 9 installer at them.
Based on Managing vSphere Lifecycle Manager Images for VMware Cloud Foundation (TechDocs) Official Architect Workshop Series #1: Converting vSphere 8 Clusters to vLCM Images Before VCF 9 (Dr Pranay Jha)
