Transition from VMware vSphere Update Manager to vSphere Lifecycle Manager

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.

Note: It is assumed that your cluster(s) consist of hosts that have identical or very similar configurations. This has been a highly-recommended best practice since the early days of VMware virtualization. If your cluster has hosts with various configurations, you can still use vLCM, but there might be some limitations when it comes to vendor add-ons, drivers, and firmware.

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.

VMware vSAN Protection and Recovery Deployment

vSAN Protection and Recovery provides a simple way to back up and restore VMs locally using vSAN Express Storage Architecture (ESA). It enables administrators to define groups of VMs along with the backup/snapshot schedule and retention times. These are crash-consistent backups that can be restored using the vSphere Client even if the VMs have been removed from inventory. Perhaps best of all is that this functionality is included with your VCF 9 license.

I plan on writing a series of blog articles about vSAN Protection and Recovery. This first article summarizes the deployment of the Protection and Recovery virtual appliance that enables this functionality. If you would like to read more about the solution itself, see the articles below.

Superior Snapshots using VMware vSAN Data Protection (2024)

vSAN Data Protection in VMware Cloud Foundation – The Solution You Already Own (2025)

VMware vSAN Protection and Recovery Enhancements for VCF 9.1 (2026)

If you read the articles above, it is easy to see that the engineers have been busy making enhancements to the feature. As such, I am going to focus on the deploying the latest version included with VCF 9.1.

First, you must download the Protection and Recovery ova from the Broadcom Support site. In this case, I grabbed the Protection-and-recovery-9.1.0.0100.25419587.ova, which was the latest version when this article was written. The numbers will be different as newer versions are released.

There are prerequisites you will need before deploying the virtual appliance from the ova file.

• Fully-qualified domain name (FQDN)/hostname for the appliance, e.g., protect02.vmware.lab
• Forward and reverse DNS lookup working properly for that FQDN, its IP address, and the FQDN and IP address of your vCenter instance.
• Hint: Use the nslookup command line interface
• Passwords to use for the appliance root account and the admin account
• You'll use admin and the corresponding password to log into the appliance UI
• NTP server
• Default gateway IP address
• Domain name and search path, e.g., vmware.lab
• Appliance IP address
• DNS server IP addresses
• Network prefix, i.e., subnet mask, e.g., 24

Deploy the appliance using the information you gathered above. Power it on after it finishes deploying and wait a few minutes to ensure it is fully booted. Access the UI by entering https://<fqdn>:5480

For example, https://protect02.vmware.lab:5480

Log in with admin and the password you set for the admin account.

Click the Configure Appliance button on the Summary page.

This starts the configuration wizard where you pair the Protection and Recovery appliance with your vCenter instance. The first step is providing information about the vCenter instance you are connecting to.

The second step simply shows the vCenter instance you specified.

The third step has a few more configuration items. Provide a descriptive site name. This might be a street or city name, a regional name, or something else that uniquely describes the environment's location. Add an email address for system notifications. In most cases, you will leave the default settings for Local Host and the Protection and Recovery Extension ID.

The appliance will perform the initial configuration after you click Finish. You will end up back at the Summary page, which shows Protection and Recovery appliance information along with the vCenter instance it is paired with.

This process installs a plugin for the vSphere Client. You will likely see a banner at the top of the vSphere Client suggesting you refresh the browser window. Click the Refresh Browser button.

If you click on the "hamburger" (three horizontal lines) ini the top left corner of the vSphere Client, you should see Protection and Recovery in the menu.

The Protect and Recovery feature is now ready for use.  We'll get to that in upcoming articles.

Upgrade from vSphere 8 to a VCF 9.1 Minimal Deployment

In the vSphere 8 era, many small environments relied on the lean duo of ESXi and vCenter for simplicity and low overhead. VMware Cloud Foundation (VCF) 9.1 evolves this model into a full-stack private cloud, offering automated lifecycle management, advanced networking, native container support, application blueprint provisioning, private AI, and much more--albeit with higher resource demands.

Fortunately, a minimal VCF installation enables smaller shops to use vCenter and ESX 9.1 without overcommitting their hardware. It is important to understand that you will not get all the full-stack VCF 9.1 private cloud features and benefits when you perform a minimal installation or upgrade.

Introduction

This article summarizes the process of upgrading vSphere 8 (vCenter 8 and ESX 8) to VCF 9.1. Detailed steps are provided in the Broadcom Technical Documentation. Below are the high-level steps. Steps 1 and 2 are the biggest differences between vSphere 8.0 and a 9.1 environment. VCF Operations and a license server are new requirements with 9.1.

1. Deploy VCF Operations 9.1
2. Deploy a license server
3. Upgrade vCenter to 9.1
4. Upgrade the ESX hosts to 9.1

As a reminder, ensure name resolution and time synchronization are implemented consistently across your environment for existing systems and new VCF components. I recommend reading the release notes from start to finish before proceeding. If you are running vSAN, verify all issues in vSAN Health are resolved before proceeding.

We start with a simple, 3-node cluster running vCenter 8 Update 3, ESX 8 Update 3, and vSAN ESA.

Deploy VCF Operations

The first step is deploying VCF Operations. I located and downloaded the Operations-Appliance-9.1.0.0.25346025.ova file from the Broadcom Support Portal. The exact file name/numbers will change as newer versions are released.

The .ova deployment is similar to other appliances. I chose the "small" deployment size considering this is a 3-node environment.

After successful deployment, I pointed a web browser to the new VCF Operations appliance. I chose the Express Installation for simplicity. This option will be best for the majority of environments. The initial setup process will take several minutes.

You will see a login screen after the initial setup is completed. Log in with the username admin and the password you specified during the .ova deployment. You will need to complete a few more setup steps.

Next, we will pair the new VCF Operations instance with the existing vCenter. Click the vCenter tile on the Home page and click the Add Account button.

Specify the vCenter instance you are connecting and add the credential--username and password for vCenter, e.g., administrator@vsphere.local. The Default collector group is fine for most environment. Click the Validate Connection button. If you have vSAN, activate the connection for vSAN, as well. Then, click the Add button.

You should see a popup notification, "Please note that collection for newly created vCenter accounts does not start automatically. After saving, initiate collection by clicking the ellipsis icon next to the vCenter Account and selecting 'Start Collecting' from the menu." We will need to perform that action next.

The Integrations page should show the newly-added vCenter instance. Expand the account and click the three vertical dots. Select Start Collecting All.

The status will likely change from Stopped to Warning. This is expected. Refreshing the view after a few moments should change the status to Collecting.

Finally, you will need to register VCF Operations with the VCF Business Service console to access and manage licenses in a 9.1 environment. Detailed instructions are in the Registering VCF Operations with the VCF Business Services console documentation. Most environments will benefit from the simplicity of configuring Connected Mode. There is a Disconnected Mode option for those that require it. Click Manage at the top of the VCF Operations screen and then click Licenses & Registration.

The first step in the licensing process is deploying a license server. This is new in version 9.1. There is virtually no interaction with the license server after it is deployed. All license management is performed in VCF Operations. A unique registration key is what ties the license server to VCF Operations.

You will need to download the license server .ova file, e.g., Vcf-License-Server-9.1.0.0.25346031.ova. Note that you will need to copy and paste the Unique Registration Key into the .ova deployment wizard.

Power on the license server once it is fully deployed. Wait a few moments to ensure it has completely booted. Then, click Review License Servers. You should see the new license server. Continue following the guidance in the UI and documentation depending on whether you are using Connected Mode or Disconnected Mode.

Upgrade vCenter to 9.1

Upgrading to vCenter 9.1 is similar to previous major version upgrades. It is a two stage process involving the deployment of a new appliance and the transfer or services and data from the old appliance to the new one. I am not going to cover the vCenter upgrade assuming that you have done it before. If you need detailed steps, see the Upgrading the vCenter Appliance documentation.

Upgrade the hosts to ESX 9.1

This is also similar to previous upgrades. vSphere Lifecycle Manager (vLCM) provides a GUI-driven, automated method to upgrade hosts including vendor add-ons and additional components, e.g., a newer driver, if needed. You can also upgrade hosts using a USB drive, CD/DVD, or the command line using ESXCLI. Start here if you need instructions: Overview of the ESX Host Upgrade Process.

vSAN

If you are running vSAN, it is likely you will need to update the disk format version. You will see a banner like the one shown below and vSAN Health will warn you, as well.

This is not a disruptive update, but it is always best to wait until a maintenance window or after normal business hours. Go to vSAN Health locate the Disk format version health check, and click the Troubleshoot button. Then click the Upgrade On-disk Format button. This is required to support some of the latest features of vSAN in VCF 9.1.

You might also see a health check warning about "vSAN optimal datastore default policy configuration." Click the Troubleshoot button to resolve that, as well. It is an excellent new feature that makes vSAN even easier to manage. You can read about it in this blog article: Auto-RAID in VMware vSAN for VCF 9.1 – Comprehensive System-Managed Data Resilience.

Conclusion

As mentioned previously, this minimal deployment provides a way to upgrade to 9.1 without the resource consumption of a full-stack VCF deployment. However, you miss out on many of the features and benefits of VCF. The good news is you can add components, as needed. For example, VCF Operations for Networks provides better visibility into your network infrastructure and can be added at a later time. A complete list of the VCF components including a brief description of their capabilities can be found here: Components in VCF and vSphere Foundation.

Why vSAN is Best for VMware Cloud Foundation

For VMware practitioners, the shift from traditional three-tier architectures to a software-defined data center (SDDC) isn't just about consolidation—it’s about regaining control. At the heart of this evolution is VMware vSAN, the native storage engine for VMware Cloud Foundation (VCF).  vSAN is the only option that delivers a full-stack, automated experience from Day 0 through Day 2 and it is included with your VCF subscription. Here is why vSAN remains the gold standard for VCF deployments.

The Power of "In-Kernel" Integration

Unlike external storage arrays that require separate management planes and complex fiber channel zoning, vSAN is embedded directly into the vSphere hypervisor.

• Minimized Latency: By residing within the hypervisor, vSAN eliminates the need to traverse separate storage networks, bringing data closer to the virtual machines (VMs).
• Unified Management: Manage both compute and storage through the familiar vSphere Client, significantly reducing the learning curve and administrative overhead.
• Feature Synergy: vSAN works seamlessly with core vSphere features like vMotion, DRS, and High Availability (HA) to ensure seamless workload mobility and resilience.
• Native vSAN-to-vSAN Replication:Replicate VMs between clusters using native workflows, eliminating the need for third-party replication tools for disaster recovery.

Performance: From OSA to ESA

With the maturity of the vSAN Express Storage Architecture (ESA), the performance gap between software-defined and proprietary hardware has effectively closed.

• NVMe Optimization: vSAN ESA is specifically designed for high-performance NVMe storage, utilizing a patented log-structured file system that optimizes writes.
• Adaptive Resynchronization: To maintain uptime, vSAN "self-heals" data after hardware failures, dynamically prioritizing VM traffic over background resynchronization tasks to ensure zero performance impact.
• Global Deduplication: vSAN ESA identifies and removes redundant 4KB blocks across the entire cluster rather than within a disk group, improving storage efficiency and reducing costs. Deduplication is background process, which avoids a performance impact to the write path.

Streamlined Lifecycle Management (vLCM)

Perhaps the most significant "quality of life" improvement for administrators is vSphere Lifecycle Manager (vLCM) integration.

• Full-Stack Patching: vLCM manages the entire stack—ESXi, vSAN, and the underlying hardware firmware and BIOS—ensuring a consistent, validated state across the cluster.
• Configuration Drift Control: Define a desired state for the cluster, and vLCM remediates deviations, reducing the risk of security vulnerabilities and instability.
• One-Click Site Maintenance: vSAN 9 introduces a Site Maintenance Mode for stretched clusters, allowing administrators to place a site into maintenance with a single click.

The Verdict

vSAN isn't just another storage option—it is a foundational building block for a modern private cloud. By eliminating siloed management and proprietary hardware lock-in, it allows IT teams to focus on delivering business value rather than managing and troubleshooting LUNs. Whether you are supporting AI, modern cloud-native apps, traditional apps, or virtual desktops, vSAN with VCF provides the scalability and resilience required for the next generation of enterprise workloads.

From vSphere 8 with VCF Operations to VCF 9

UPDATE: Consider deploying VCF 9.1. It is the latest version of VCF that includes new features and functionality, as well as, the latest bug fixes and security updates. This blog article discusses upgrading from vSphere 8 to a minimal installation of VCF 9.1: Upgrade from vSphere 8 to a VCF 9.1 Minimal Deployment

This post is a followup article to VCF Operations 9 with vSphere 8 for smaller shops ready to make the jump to VMware Cloud Foundation (VCF) 9. A high-level overview is provided here. This article is not step-by-step instructions. See the VCF documentation for detailed guidance. The assumption from a licensing perspective is that your organization purchased a VCF subscription.

Prerequisites

You must upgrade vCenter from version 8 to 9 prior to deploying VCF. The ESX hosts can remain on 8. The steps for upgrading vCenter are similar to the past few versions. Guidance on upgrading vCenter can be found here: vCenter Upgrade.

Your vCenter and hosts will also need to be using a Distributed Virtual Switch (DVS). Otherwise, you will see messages like the screen shot below when you get to the Validate & Deploy step in the VCF Installer deployment wizard. See Migrating from Standard to Distributed vSwitch for guidance, if needed.

VCF Installer

Begin by deploying the VMware Cloud Foundation Installer virtual appliance from the OVA file. The OVA can be downloaded from the Broadcom Support Portal. Perhaps the easiest way to find the VCF downloads is to click Downloads in the left column and enter "foundation" in the Search Product Name field. The item you need will look like this: VCF-SDDC-Manager-Appliance-x.x.x.x.xxxxxxxx.ova where the x's are a specific version number. Why is it not named VCF-Installer? The Installer appliance becomes the SDDC Manager appliance after installation. Note that you will need to have an IP address, DNS record, etc. set aside for use with this appliance just like most other VMware virtual appliance deployments.

After the appliance is deployed, point your web browser to the appliance FQDN or IP address and log in with the admin@local password you provided during deployment. One of the first things you will need to do is configure a depot connection to enable downloads. The easiest method is an online depot using your download token. For those in air-gapped/disconnected environments, an offline depot can be set up.

Ensure you have IP addresses, DNS records, NTP settings, etc. for the other appliances that will be deployed as part of VCF.

• Fleet Management appliance
• Operations Collector appliance
• NSX virtual IP (VIP)
• NSX Manager appliance

Download the components you will be using in Depot Settings. In my example below, I am not deploying VCF Automation at this time so it is not selected. I already upgraded vCenter to 9.0.2 so that component is not needed.

Wait until all of the components you are downloading have a "Success" status before proceeding.

In the Deploy section, click Deployment Wizard and select VMware Cloud Foundation. Next, choose the "Deploy a new VCF fleet" radio button and click Continue. We will use existing VCF Operations and vCenter components.

Complete the General Information step as desired. Select the "Standard (Single-node)" radio button to minimize the resource consumption of the VCF management appliances.

In the next step, you will specify your existing VCF Operations instance. VCF requires two additional operations appliances: Fleet Management Appliance and Operations Collector Appliance. Provide the FQDNs and passwords for these components.

VCF Automation deployment is optional. It can be deployed later, if needed.

Next, you will enter the details for your existing vCenter instance. As mentioned previously, you must be running vCenter 9.

NSX Manager is deployed as part of VCF regardless of whether you plan to use NSX overlay capabilities. I chose to keep with a VLAN-backed configuration as shown in the screen shot below. Note that you will need two FQDNs and IP addresses for NSX.

The VCF Installer becomes SDDC Manager as part of the installation process. We simply need a password for SDDC Manager.

Ensure all of the validations succeeded. If not, remediate all issues and re-run the validation until all show a Succeeded status.

Then click Deploy, grab some popcorn, and watch as the VCF Installer converts the environment from vSphere with VCF Operations to VCF.