This is the first post in my new Architect Workshop Series — short field notes from real VMware Cloud Foundation workshops and assessments, written up as deep dives. The goal is simple: capture the questions customers actually ask in the room, and answer them properly so the next engineer has a reference to point to.

Workshop context

I recently attended a VCF workshop where the customer was evaluating their existing vSphere 8 estate with one clear ambition: converge it into a modern, fleet-managed VMware Cloud Foundation 9 (VCF 9) platform. Classic modernization story — they had grown a solid vSphere footprint over the years, and now they wanted the single-SDDC, lifecycle-as-a-fleet experience that VCF 9 promises.

As we walked the assessment sheet cluster by cluster, we hit their development vCenter — I’ll call it dev-vc01. The lifecycle status jumped out immediately: the cluster was still Baseline-managed using the legacy vSphere Update Manager (VUM) model, and it was even carrying one non-compliant baseline. My recommendation on the sheet was blunt: Need action — convert this cluster to vLCM Image-based management before we go anywhere near VCF 9.

Then came the fair question every good customer asks:

That single question is what this whole post is about — because the answer is not a matter of preference or best practice. In VCF 9 it is a hard gate.

Short answer

vLCM is not optional for VCF 9. It is a prerequisite. Starting with vSphere / vCenter 9.0, the legacy Baseline (VUM) lifecycle mode has been removed. Every cluster and standalone host must be managed with vSphere Lifecycle Manager (vLCM) Images. If you attempt to bring a baseline-managed cluster into VCF 9, the installer validation will fail. So the direction of travel for dev-vc01 is fixed: convert from Baselines to Images first, then proceed with the VCF 9 work.

Baselines vs. vLCM Images

To understand why Broadcom drew a hard line here, you have to see that Baselines and Images are not two flavors of the same tool. They are two fundamentally different models for how a host’s software state is defined.

Baselines: vSphere Update Manager (VUM)

Baselines are additive and incremental. You attach a baseline (or baseline group) to a cluster — Critical Host Patches, Non-Critical Host Patches, a specific upgrade baseline — and vCenter checks each host for compliance against that set of patches. You remediate, and patches get layered on top of whatever is already there. Over time each host becomes the sum of its patch history. Two hosts that are compliant can still carry subtly different driver and firmware states, because a baseline only asserts these patches are present, not only this exact software set exists. That single non-compliant baseline on dev-vc01 is a perfect example of how baseline drift quietly accumulates.

vLCM Images

A vLCM Image is declarative and desired-state. Instead of describing patches to add, you define the complete software specification the entire cluster should run, built from four layers:

• ESXi base image — the exact ESXi version for every host.
• Vendor add-on — the OEM customization (Dell, HPE, Lenovo, and so on).
• Firmware and drivers add-on — delivered through the Hardware Support Manager (HSM), so firmware becomes part of the same desired state.
• Independent components — additional drivers or tools you pin explicitly.

vLCM then enforces that image across the whole cluster. Every host converges to the same bit-for-bit software state — no drift, no archaeology about which patches a host actually received in 2022. Compliance becomes binary: a host either matches the image or it does not, and vLCM remediates it back to the declared state. This is the same desired-state philosophy that makes VCF’s fleet lifecycle possible in the first place.

Why VCF 9 makes vLCM mandatory

Here is the timeline I walked the customer through, because context matters.

So when the VCF 9 installer validates the environment and finds a cluster still using baselines, it is not being fussy — it literally cannot lifecycle-manage that cluster the old way anymore. The validation fails by design. This is exactly the scenario Broadcom documents in the VCF installer validation KB the customer was pointed to.

There is also a deeper architectural reason. VCF 9 leans on fleet-level lifecycle management — managing many clusters and workload domains as a coordinated fleet. Fleet management only works if every cluster speaks the same declarative, desired-state language. A baseline-managed cluster is an island the fleet manager cannot reason about deterministically. Images give VCF the guarantee it needs: every host in every domain is exactly what the image says it is.

Customer concerns, answered

Under the why, the customer’s actual worry was not philosophical — it was operational risk. Three concerns came up, and they are worth answering plainly.

Remediation runbook: Baselines to Images

Here is the practical sequence I recommended for dev-vc01. Always confirm the exact steps for your target version against the Broadcom KB linked below, but this is the shape of the work.

1. Pre-flight the hardware. Confirm all hosts are on the Broadcom Compatibility Guide for your target ESXi, and that a Hardware Support Manager (HSM) is available if you want firmware managed in the image. Heterogeneous clusters need this check most.
2. Clear existing compliance noise. Resolve that one non-compliant baseline first. Going into a conversion with a known-dirty state just makes the before/after harder to reason about.
3. Back up vCenter and record current host build numbers, drivers, and firmware. You want a clean rollback reference and a clear record of where you were.
4. Start the conversion. In the vSphere Client, on the cluster Updates tab, choose to manage the cluster with a single image. vLCM can seed the image from an existing host — a great way to capture the current running state.
5. Define the desired image. Select the ESXi base image, the correct vendor add-on, and (via HSM) the firmware/driver add-on. Pin any independent components.
6. Check compliance. Let vLCM scan the cluster against the new image and review the drift report. This is your dry run — nothing changes yet.
7. Remediate on a rolling basis. Host-by-host with maintenance mode and vMotion, exactly as you would for any patch cycle. Validate workloads between hosts.
8. Confirm and document. Verify the whole cluster reports compliant against the image, update your runbook, and mark the assessment line item as remediated.

Do this on the dev cluster first (which is exactly what the assessment flagged), prove the pattern, then repeat it across the remaining clusters before the VCF 9 build begins.

Field takeaways

• vLCM Images is mandatory for VCF 9 — baselines/VUM are removed in vSphere 9.0. This is a gate, not a recommendation.
• Convert before you deploy. A baseline-managed cluster will fail VCF 9 validation. Fix it in a calm, planned window — not at go-live.
• The conversion is low-risk and non-disruptive when planned: seed the image from a host, check compliance, remediate rolling.
• Start with dev. Prove the pattern on the low-blast-radius cluster, then scale it out.
• Images unlock the point of VCF in the first place — desired-state, drift-free, fleet-manageable lifecycle.

So the honest answer to the customer’s question — Is vLCM optional or needed before deployment? — is that it is needed, full stop. And the good news is that the work to get there is straightforward, low-risk, and best done now while there is no deadline breathing down your neck.

References

• Broadcom KB — VCF Installer 9.0 validation fails when a cluster is baseline-managed: knowledge.broadcom.com/external/article/443265
• Broadcom KB 385617 — Transitioning VUM/baseline clusters to vLCM (VCF 5.2.2+ and VCF 9).
• Broadcom TechDocs — vSphere 9.0: vSphere Lifecycle Manager Images and Baselines
• Broadcom KB 322186 — Managing ESXi host lifecycle operations with vLCM Images

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts