Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

For vSphere 9, use vSphere Lifecycle Manager Images (vLCM Images) for ESXi host lifecycle management. Broadcom has removed major vSphere Lifecycle Manager Baselines functionality in vSphere 9 and directs customers to move to image-based management. In vSphere 8, baselines remain available, so an existing environment can continue using them while you plan and validate a transition.

Manual work does not disappear with vLCM. A disconnected site may still require an administrator to download an ESXi offline bundle, transfer it securely, import it into the vLCM depot and remediate hosts. The practical choice is therefore not simply “automation versus manual patching.” It is whether your release, hardware and operating model support a desired-state image, and how much package handling your site requires.

The decision in one view

Choose vLCM Images when your vCenter and ESXi versions support them and you want a declared host state, cluster-wide consistency, compliance checks, and lifecycle handling for supported vendor add-ons, drivers and firmware. This is the forward-compatible path for vSphere 9 and the route required for existing baseline-managed ESXi 8.x clusters or standalone hosts that must move to ESXi 9.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Keep an existing baseline workflow only when you are on a release that still supports the required baseline functions, your hardware and patches fit that workflow, and you have a documented reason to delay conversion. Treat that as a transition decision, not evidence that baselines will remain available in the next major release.

Question vLCM Images Baseline or manual workflow
What is managed? A desired state for the ESXi image, with supported vendor add-ons, components, firmware and drivers. Selected bulletins, patches, extensions or an imported image are attached and applied through older update workflows.
How is compliance assessed? Lifecycle Manager compares hosts with the cluster image and reports drift before remediation. Hosts are checked against attached baselines or updated individually according to the chosen package set.
Best release fit Required direction for vSphere 9; also available in supported vSphere 8 deployments. Still available in vSphere 8, but major baseline functions are removed in vSphere 9.
Disconnected sites Offline ZIP bundles can be imported into the image depot and then used for normal image compliance and remediation. Packages may be selected and moved manually, but host-by-host handling can leave configuration differences.
Firmware and driver lifecycle Can represent these in the image when the server vendor and hardware support the integration. Usually requires separate vendor tools or package decisions; exact capabilities vary by platform.
Rollback of a conversion Do not assume reversibility. Broadcom’s documented baseline-to-single-image conversion procedure states that the conversion cannot be reverted. An existing baseline attachment remains in place until you deliberately change the workflow.

What vLCM Images actually manage

Desired-state image

An image is a target definition rather than a list of ad hoc patches. You select a target ESXi base version and, where supported, add the vendor add-on, additional components, firmware package and driver versions that belong with that host platform. Lifecycle Manager evaluates every host in the managed scope against that definition.

If a host drifts because an administrator installs or removes a component, changes a driver or applies an update outside the image, compliance checking exposes the difference. Remediation brings the host back toward the declared state. The result is a repeatable cluster configuration instead of a separate patch history for every server.

Scope and assignment

Images can be assigned and remediated at vCenter, datacenter or folder scope in the vSphere 9 operating model described by VMware. The exact scope you choose should match your hardware uniformity and change-control boundaries. A broad assignment is efficient only when the hosts share the image’s compatibility requirements; otherwise, use smaller clusters or folders with appropriately different images.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Baselines are a different model

Baselines group update bulletins and attach those groups to hosts or clusters for compliance and remediation. Administrators may select patches and extensions manually or import an ISO. This model can be familiar and useful on vSphere 8, but it does not provide a safe assumption that the same controls will exist after a vSphere 9 upgrade.

What “manual patching” means in practice

Manual patching can describe several activities, so define it before comparing it with vLCM. One administrator may mean selecting individual bulletins and remediating hosts one at a time. Another may mean downloading an ESXi offline ZIP on an internet-connected machine and carrying it to a dark site. The second activity is manual package handling, but the remote cluster can still be managed by a vLCM image after the bundle is imported.

vLCM does not remove the need to understand the package, verify compatibility or schedule host maintenance. It changes where the desired version is declared and how drift is checked. A team that keeps a fully manual, host-by-host process must maintain its own records of installed versions, drivers, extensions and exceptions; an image-managed team delegates much of that consistency check to Lifecycle Manager.

Release-specific rules you must check

vSphere 9

Broadcom’s current lifecycle guidance says major vSphere Lifecycle Manager Baselines functionality is removed in vSphere 9 and recommends transitioning ESXi clusters to vLCM Images. VMware’s vSphere in VCF 9.0 overview, published June 23, 2025, states that existing baseline-managed ESX 8.x clusters and standalone hosts must move to image-based management to upgrade to ESX 9. New clusters and hosts cannot be baseline-managed.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Do not plan a vSphere 9 project around an assumption that an ISO or legacy baseline path will remain available. Confirm the exact vCenter and ESXi build, the supported upgrade destination and the conversion process for your cluster before approving the change.

vSphere 8

Broadcom’s vSphere 8 guidance describes baseline management as deprecated but still available in vSphere 8 until removal in the next major release. That gives an existing vSphere 8 team time to inventory hardware, test an image, and schedule conversion. It does not make a baseline configuration portable to vSphere 9 without a supported transition.

VMware Cloud Foundation

VCF has additional transition rules. Broadcom identifies VCF 5.2.2 and later and VCF 9 as versions with supported transition guidance. Customers on older VCF versions should upgrade first rather than attempting the conversion directly. Use the VCF-specific bill of materials and lifecycle documentation for your release, not a generic vSphere procedure.

Use this decision framework before choosing

1. Confirm the upgrade path

Record the vCenter Server version, every ESXi version, the VCF release if applicable, and whether the target is a patch, an update or a major-version upgrade. A workflow that is valid for vSphere 8 may be unavailable in vSphere 9. If the business objective is ESXi 9, include image conversion as a project prerequisite rather than treating it as an optional optimization.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

2. Check hardware and component uniformity

For each host, inventory the server make and model, installed VIBs and components, storage and network devices, firmware levels, and any vendor add-on already in use. Compare that inventory with the image’s hardware support. A cluster cannot be made uniform merely by assigning the same ESXi base version if one host needs a different driver or firmware package.

Early vSphere 7 image guidance listed same-vendor hosts as a prerequisite for that workflow. Later VCF 9 material describes mixed-vendor clusters and multiple hardware support managers. Treat the older restriction as historical rather than universal, but verify the current support matrix for your exact servers and managers.

3. Validate firmware and driver integration

An image can include firmware and driver state when the OEM integration supports the platform. That integration is not guaranteed for every server, device or firmware tool. Confirm the vendor add-on, hardware support manager and supported firmware catalog for the precise model and release. If a required device is outside that integration, document how it will be maintained and tested.

4. Verify depot access

Connected vCenter deployments can obtain depot content, but access is an operational dependency rather than an assumption. Broadcom notes that public depot download URLs are now customer-specific and may need reconfiguration when new releases are not visible. Test entitlement, credentials, proxy or firewall rules and the visibility of the target ESXi build before the maintenance window.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

For a disconnected site, decide where downloads will be made, how bundles will be scanned and transferred, who can import them, and how the file’s integrity and provenance will be recorded. An image workflow still needs a reliable depot, even when that depot is populated manually.

5. Estimate disruption for the specific patch

Image remediation may evacuate workloads, place hosts in maintenance mode, reboot them and return them to service in batches. The impact depends on the patch, cluster capacity, admission-control settings, storage behavior and network design. Build a host sequence that preserves enough capacity for workloads and leaves time to recover a failed remediation before proceeding to the next batch.

6. Confirm conversion and rollback boundaries

Read the conversion procedure for the exact release and cluster type. Broadcom’s Live Patch documentation explicitly says that its conversion from baselines to a single image cannot be reverted. Treat the conversion as a one-way change unless current documentation for your environment states otherwise. Export configuration information, capture compliance results and test the image on a representative cluster before converting production.

How an image-based remediation cycle works

  1. Inventory. Record host builds, vendor add-ons, components, firmware, drivers, storage paths, network devices and any unsupported or locally installed VIBs.
  2. Define the image. In Lifecycle Manager, select the supported ESXi base image and add only the vendor add-ons, components, firmware and drivers required by the host hardware.
  3. Run compatibility checks. Review image validation and cluster compatibility results. Resolve conflicts instead of forcing a remediation that would remove a required device driver or component.
  4. Test on a representative host or cluster. Confirm boot, storage, networking, management connectivity, monitoring and workload behavior after remediation.
  5. Schedule the change. Coordinate workload evacuation, backup verification, application-owner notifications and a host-by-host sequence.
  6. Run the compliance pre-check. Inspect blockers, maintenance-mode requirements, hardware warnings and any host that cannot accept the image.
  7. Remediate in controlled batches. Start with a canary host or small cluster, verify health, then continue through the approved sequence.
  8. Verify after remediation. Check host connectivity, datastores, vSAN or storage health where applicable, distributed switches, device paths, alarms and the final image compliance state.

Live Patch: useful, but not a no-downtime promise

Broadcom’s Live Patch feature can apply eligible security patches and urgent bug fixes to image-managed clusters without placing virtual machines into maintenance mode or rebooting them for those particular patch operations. It is disabled by default and applies only when every stated condition is met.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Requirement or limitation Operational meaning
vCenter and all cluster ESXi hosts on 8.0 Update 3 or later An older host in the cluster prevents use of the feature until the version requirement is met.
Single vLCM image The cluster must use one image definition rather than a baseline-managed or mixed image arrangement.
Compatible hosts and eligible target patch Only patches approved for Live Patch and hardware that supports the operation qualify.
TPM devices Broadcom lists TPM devices as an incompatibility for Live Patch.
DPUs using vSphere Distributed Services Engine These DPUs are listed as incompatible and require the ordinary remediation path.
Host that needs maintenance mode The live operation is blocked; plan a conventional remediation with workload evacuation and, if required, a reboot.

Run the remediation pre-check and read the release notes for the target patch. “Patch without downtime” is too broad: Live Patch is conditional on release, image state, hardware and patch content, and it does not replace maintenance planning.

Air-gapped and remote-site procedure

Broadcom documents an offline process for remote, dark and air-gapped environments that do not have direct access to Broadcom or VMware online depots. The cited procedure covers ESXi and vCenter 7.x and 8.x; verify current instructions before applying the same process to a newer release.

  1. Download the bundle on a connected machine. Obtain the ESXi offline patch ZIP from the Broadcom Support Portal. Confirm that the bundle matches the intended ESXi release and your entitlement.
  2. Transfer it securely. Move the ZIP to a system that can reach vCenter at the remote site using your approved media-transfer and malware-scanning process. Preserve the original filename and record the transfer.
  3. Open Lifecycle Manager in vSphere Client. Navigate to Lifecycle Manager and import the update ZIP into the image depot.
  4. Edit the cluster image. Select the imported base image, or the appropriate package represented by the bundle, in the target cluster’s image definition.
  5. Run the image compliance pre-check. Review compatibility errors, missing components, maintenance-mode requirements and any host-specific blocker.
  6. Remediate. Remediate all hosts together only when the cluster can tolerate the sequence; otherwise select hosts individually or use controlled batches.
  7. Verify the result. Confirm that each host is connected, workloads and storage are healthy, and the cluster reports compliance with the intended image.

This process combines manual package transfer with automated desired-state management. The absence of internet connectivity is not, by itself, a reason to abandon vLCM.

Moving from baselines to images safely

Prepare before conversion

  • Document the current baseline attachments, patch level, installed VIBs, extensions, drivers and firmware.
  • Identify hosts that differ from the rest of the cluster and determine whether the differences are supported by a single image.
  • Check VCF release prerequisites if the cluster belongs to VMware Cloud Foundation.
  • Confirm depot access or prepare the offline bundle and import path.
  • Test the candidate image and remediation sequence on non-production or a representative cluster.
  • Obtain change approval that acknowledges conversion and rollback limits.

Convert and validate

  1. Open the cluster’s Lifecycle Manager image configuration and select the supported base image.
  2. Add the vendor add-on and required components only after checking hardware compatibility.
  3. Run the image validation and compliance pre-check.
  4. Resolve blockers such as unsupported VIBs, incompatible drivers, firmware mismatches or hosts that cannot enter maintenance mode.
  5. Remediate using the approved host sequence.
  6. Recheck compliance and application health before converting another production cluster.

Do not describe this as a temporary experiment if the documented procedure is non-reversible. Keep the pre-conversion inventory and test evidence as part of the operational record.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Common failure modes and fixes

The target image is not visible

Check customer-specific depot URLs, entitlement, proxy and firewall configuration, and the account used by vCenter. If the site is disconnected, download the correct offline ZIP on a connected machine and import it into the depot instead of waiting for an online catalog refresh.

Best Value
Forvencer Server Book, 2 Zipper Pocket, Server Books for Waitress
  • Upgraded Two Zipper Pockets: Forvencer server books feature two secure zipper pockets for better organization of coins, cash, and receipts, ensuring that everything you collect has a safe and secure place
  • Smart Storage & Quick Access: Designed with 8 multi-functional compartments, the right side includes a guest receipt pad, while the left has a money pocket, ticket pocket, and credit card slot. Two small clear pockets store bills, receipts, and other visible items. A stitched pen loop ensures you always have your favorite pen ready
  • High-quality & Easy to Clean: Crafted from high-quality PU leather with heavy-duty stitching, this server book is built to last. It resists tears, scratches, and its waterproof surface makes cleaning easy with just a damp cloth or a non-chlorine sanitizer
  • Perfect Fit for Your Apron: Measuring 5” x 8”, this compact organizer is slightly smaller than other models, making it ideal for bending or sitting while carrying in your server apron. It holds everything a waitress needs—a place for everything
  • What's Included: This server organizer comes with multiple open and zippered pockets to store money, receipts, tips, etc. Clear sleeves are perfect for keeping menus or special lists while serving. Available in a variety of colors, allowing you to express yourself even when in uniform

A host fails the image pre-check

Compare the host’s VIBs, components, drivers, firmware and hardware model with the image and vendor add-on. Remove or replace only items that are confirmed as unsupported, and obtain a supported package for any device that the image requires. Do not ignore a blocker simply to make the compliance screen green.

Hosts in one cluster need different drivers

Determine whether the differences are supported by the current hardware support manager. If one image cannot represent the cluster safely, separate hosts into compatible clusters or use distinct image scopes rather than forcing a lowest-common-denominator driver.

Remediation cannot evacuate a host

Inspect active workloads, admission-control capacity, pinned virtual machines, storage accessibility and networking dependencies. Free capacity or move workloads before retrying. If the patch is Live Patch-ineligible, schedule the required maintenance mode and reboot.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The team expects Live Patch to handle every update

Check the target patch’s eligibility, host versions, image arrangement, TPM or DPU presence and the pre-check result. Use the ordinary remediation workflow whenever one requirement fails.

A vSphere 8 baseline plan is being carried into vSphere 9

Stop the upgrade plan and map the cluster to a supported image workflow first. Existing baseline-managed 8.x clusters and standalone hosts need image-based management for the stated ESXi 9 upgrade path, and new vSphere 9 hosts cannot be baseline-managed.

Practical choices by environment

Connected vSphere 9 cluster

Build and validate a vLCM image, verify that the customer-specific depot exposes the target release, test remediation on a representative host, and use the image for ongoing compliance. A baseline-first design creates an avoidable upgrade dependency because major baseline functionality is removed in vSphere 9.

Existing vSphere 8 cluster with stable baselines

You can continue the supported baseline workflow while you inventory hardware and test conversion, provided the release still supplies the functions you need. Set a target date and prerequisites for moving to images rather than treating the vSphere 8 exception as a permanent operating model.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Air-gapped vSphere 8 site

Use the documented offline ZIP transfer, import the bundle into Lifecycle Manager and manage the target cluster with an image. The transfer is manual; compliance, pre-checks and remediation remain centralized.

VCF environment on an older release

Do not apply the VCF 5.2.2 or VCF 9 transition procedure to an older VCF version without first upgrading to a supported release. Follow the VCF bill of materials and lifecycle instructions for the installed version.

Questions to answer in your change record

  • Which exact vCenter, ESXi and VCF releases are installed and targeted?
  • Is the destination vSphere 9, making image management a prerequisite?
  • Can all hosts in the proposed scope use the same base image, vendor add-on, drivers and firmware?
  • Are any TPM devices or DPUs using vSphere Distributed Services Engine present?
  • Does the target patch qualify for Live Patch, or will hosts require maintenance mode and reboot?
  • Is depot access working, or has the offline ZIP been downloaded, verified and transferred?
  • What is the host remediation order, and is there enough cluster capacity for evacuation?
  • What evidence demonstrates application, storage, network and management health after remediation?
  • Does the conversion procedure permit reversal? If not, what is the approved recovery plan?

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.