As vSphere and VCF environments scale in complexity, lifecycle management is longer be an afterthought. For years, vSphere administrators relied on vSphere Update Manager (VUM) to patch and upgrade ESXi hosts. Starting with vSphere 7 and solidifying its position in vSphere 8, VMware introduced vSphere Lifecycle Manager (vLCM), changing the update methodology.
With VUM and baseline-centric approaches deprecated in vSphere 8, transitioning to vLCM is no longer just recommended—it is required before moving to version 9. This article covers the technical differences, the transition process, and the gotchas every vSphere admin needs to know.
Imperative vs. Declarative Management
The core difference between VUM and vLCM is their operational models:
- vSphere Update Manager (Imperative Model): You manually define baselines (groups of patches or ISOs), attach them to a cluster, scan for compliance, and remediate. It’s highly manual and generally only handles the hypervisor software, leaving driver and firmware drift up to human oversight.
- vSphere Lifecycle Manager (Declarative Model): You define a single "desired state" image for the entire cluster. This image encompasses the ESXi version, vendor add-ons, individual components, and firmware in some cases. vLCM compares hosts to this image. If there are differences, vLCM notifies you and orchestrates the updates to bring the hosts back into compliance.
Modern Capabilities of vLCM in vSphere 8 and Beyond
If you are still thinking of vLCM as just "the new VUM," you are missing out on powerful and beneficial capabilities:
- Comprehensive Host Lifecycle Management: By integrating with Hardware Support Managers (HSMs) like Dell OpenManage Enterprise Integration for VMware vCenter (OMEVV), HPE OneView, or Lenovo XClarity, vLCM can patch the hypervisor, drivers, and server firmware in a single orchestrated reboot cycle.
- vSphere Configuration Profiles (vCP): Replacing legacy Host Profiles, vLCM now integrates deeply with vCP to manage and enforce configuration drift across clusters using JSON payloads, entirely removing the pain points of the old Host Profile engine.
- Standalone Host Support: vLCM is not limited to cluster-bound hosts. You can manage standalone ESXi hosts at the edge via API using the same desired-state image model.
- DPU/SmartNIC Management: With vSphere Distributed Services Engine (vDSE), vLCM fully manages the lifecycle of Data Processing Units alongside the host ESXi installation.
Pre-Flight Checklist: Preparing for the Transition
Before you click the "Manage with a single image" button in vCenter, complete this checklist:
- Check Interoperability: Verify that your ESXi hardware are fully compatible using the VMware Interoperability Matrix.
- Update vCenter: Ensure that you are running the latest version of vCenter to utilize the latest features, bug fixes, and security patches. See this knowledge base article.
- vMotion and Distributed Resource Scheduler (DRS): Ensure these are configured and working properly. This enables vLCM to automatically migrate VMs to and from hosts to avoid application downtime.
- Deploy your HSM: If you plan to use the firmware management capability, ensure your server vendor’s HSM plugin is installed, registered with vCenter, and fully authenticated. This is highly recommended for vSAN clusters. See this documentation for more details.
- Review Auto Deploy Infrastructure:Stateless hosts (Auto Deploy) historically had limitations with vLCM. If you run a heavily stateless environment, review the latest vSphere 8 architecture designs and recommendations to ensure compatibility before migrating.
Step-by-Step Migration Guide
Converting a cluster to vLCM is a one-way operation. You cannot revert a cluster to baseline management once converted.
Initiate the Transition: Navigate to your target cluster in the vSphere Client. Go to Updates > Manage with a single image.
Define the Desired Image:
- ESXi Version: Select your base image (e.g., ESXi 8.0 Update 2).
- Vendor Add-on: Select the OEM-specific add-on (e.g., Dell custom drivers).
- Firmware and Drivers Add-on: Connect this to your HSM plugin.
- Components: Add any individual, validated third-party VIBs.
If your hosts are running the same build and they are current, you will see the option to proceed with that image. If there is more than one build you will see multiple options and which one is the highest version. You can select the desired image for the cluster from those options.
You can also import an image using a .json file (knowledge base article) or build an image manually. In this case, I will build the image manually to select the latest ESXi build for the cluster. You should see several builds to choose from in the drop-down list. If you do not, it is probably because you do not have the custom Broadcom download URLs configured in vSphere Lifecycle Manager. See this knowledge base article for guidance. Article 390121 will be of particular interest. Your Patch Setup settings should look similar to the image below.
If configured properly, you should see several ESXi versions/builds including the latest ones. I will select the most recent version of ESXi 8 Update 3 as of the publication date of this article.
Next, I select the appropriate vendor add-on, as needed. Note there are various versions of these add-ons, as well. Verify you are selecting the correct add-on--in most cases, the most recent one. Clicking the add-on will provide a detailed list of the software included in that add-on such as what drivers and their versions.
If you intend to update firmware with vLCM, you will need to set up the Hardware Support Manager as briefly discussed earlier in this article. This is especially beneficial for environments running vSAN.
Finally, you can add components such as a newer, async release of VMware Tools.
Click Save to save the custom image you just built. vLCM will check image compliance for the cluster. Click Finish Image Setup and you are ready to start using a vLCM desired state image to update your cluster.
Check Compliance: This is where vLCM compares the current running state of the ESXi hosts with your newly defined image.
Remediate All: Once readiness checks pass and you are satisfied with the compliance report, click Start Remediation. The hosts will enter maintenance mode, apply the updates, and reboot sequentially.
Best Practices & Common Gotchas for Admins
Watch out for these potential issues:
The "Standalone VIB" Blocker (The #1 Issue): When you run the Cluster Readiness check, you might see warnings about existing VIBs on the ESXi hosts that are not defined in the new vLCM image. Common culprits include legacy backup agents, deprecated monitoring tools, and old third-party drivers. The Fix: You must either remove these rogue VIBs manually via SSH using esxcli software vib remove -n <vib_name> (which often requires a reboot), or you must track down the updated zip package for that VIB and add it to your vLCM Image Components.
Incompatible Hardware and CPUs: vLCM is strictly enforced. If you have hosts in the cluster with CPUs that are no longer supported by the target ESXi version, vLCM will block the remediation. There is no easy "override" for unsupported hardware in a declarative model. Ensure cluster uniformity. See this knowledge base article for more information about supported hardware with ESX 9.x.
Utilize ESXi Quick Boot and Staging: To drastically reduce maintenance windows, take advantage of two key vLCM features:
- Staging: Pre-download the payload to the ESXi hosts prior to your maintenance window.
- Quick Boot: Enable this in the vLCM cluster settings. Quick Boot skips the hardware POST (Power-On Self-Test) sequence, rebooting only the hypervisor kernel. On heavy enterprise servers, this can turn a 15-minute reboot into a 2-minute reboot.
vSAN Express Storage Architecture (ESA): If you are running vSAN ESA, vLCM is mandatory for ensuring hardware compatibility. Because ESA is reliant on specific NVMe drive firmware and controller queues, vLCM’s deep integration with vSAN hardware compatibility checks (vSAN HCL) ensures you never inadvertently push an unsupported storage driver into production.
Wrapping Up
Moving from vSphere Update Manager to vSphere Lifecycle Manager is more than just learning a new tool—it is an evolution in systems management. By adopting a declarative, desired-state model and integrating firmware management directly into vCenter, vSphere administrators can significantly reduce operational overhead, eliminate configuration drift, and ensure highly consistent clusters.
