7.2 Baseline-Based Lifecycle Management

7.2 Baseline-Based Lifecycle Management

While vSphere Lifecycle Manager (vLCM) cluster images represent VMware's modern declarative standard, baseline-based lifecycle management remains widely deployed across legacy clusters, heterogeneous hardware environments, and standalone host topologies. The vSphere 8.0 release notes deprecate baselines: they remain supported in vSphere 8 but will be removed in a future major release. Historically known as vSphere Update Manager (VUM), baseline management operates on an additive, imperative model. Rather than defining a complete holistic hypervisor image, baselines scan ESXi hosts for specific missing software patches, security bulletins, or third-party extensions, and layer those updates incrementally on top of the host's existing operating state.

Understanding the mechanics of predefined baselines, custom baselines, baseline groups, and cluster remediation orchestration is critical for managing transitional environments and answering key architectural questions on the VCP-DCV exam.

Taxonomy of Baselines and Baseline Groups

In baseline management, software updates are organized into specific objects termed Baselines. Baselines can be attached to individual standalone hosts, clusters, datacenters, or entire inventory folders.

+-------------------------------------------------------------------------+
|                         Baseline Group Architecture                     |
|                                                                         |
|   +-----------------------------------------------------------------+   |
|   | Host Upgrade Baseline (Maximum: Exactly 1)                      |   |
|   | Targets Major ESXi Version Upgrade (e.g. ESXi 7.0 to ESXi 8.0)  |   |
|   +-----------------------------------------------------------------+   |
|                                   +                                     |
|   +-----------------------------------------------------------------+   |
|   | Host Patch Baselines (Multiple Allowed: Fixed or Dynamic)        |   |
|   | Critical Security Bulletins, Cumulative Bug Fixes, Rollups      |   |
|   +-----------------------------------------------------------------+   |
|                                   +                                     |
|   +-----------------------------------------------------------------+   |
|   | Host Extension Baselines (Multiple Allowed: Vendor/Third-Party) |   |
|   | Async Storage/NIC Drivers, OEM CIM Providers, VAIO Filters      |   |
|   +-----------------------------------------------------------------+   |
+-------------------------------------------------------------------------+

1. Predefined Baselines

vCenter Server provides three predefined baselines that update automatically as the depot synchronizes: Critical Host Patches, Non-Critical Host Patches, and Host Security Patches. As of vSphere 8.0 they contain VMware content only; third-party async drivers and tools must go into custom baselines.

• Critical Host Patches: Contains all bulletins classified with a severity level of Critical or Important, focusing on VMware Security Advisories (VMSAs) and critical hypervisor stability fixes. As VMware releases new critical security patches, they are automatically incorporated into this baseline.
• Non-Critical Host Patches: Encompasses bug fixes, stability improvements, minor performance patches, and low-to-moderate severity bulletins.

2. Custom Baselines

Administrators can create custom baselines tailored to organizational compliance policies and specific hardware configurations:

• Host Patch Baselines: Created to bundle hypervisor patches according to strict organizational requirements. Custom patch baselines can be configured as:
  • Fixed Baselines: Contain a static, immutable list of specific bulletins manually selected by the administrator. Even when vCenter downloads newer patches, a fixed baseline never changes, making it ideal for validated change-control freezes.
  • Dynamic Baselines: Defined by dynamic criteria (Vendor, Severity: Critical/Important/Moderate/Low, Category: Security/BugFix/Enhancement, and Release Date range). As vCenter synchronizes new bulletins from the depot matching the specified criteria, the baseline dynamically updates itself.
• Host Extension Baselines: Designed to package software components that do not originate from standard VMware hypervisor patch bundles. Extensions include third-party storage multipathing software (e.g., Dell PowerPath), specialized asynchronous network drivers, CIM monitoring providers, or backup filter drivers. Unlike patches, extension packages do not supersede or overwrite newer versions unless explicitly forced, but they take precedence over standard base image components during evaluation.
• Host Upgrade Baselines: Used to perform major hypervisor version upgrades (for example, upgrading ESXi 7.0 Update 3 to ESXi 8.0 Update 2). An upgrade baseline requires the administrator to upload an official VMware ESXi installer ISO image into the vSphere Lifecycle Manager depot.

3. Baseline Groups

A Baseline Group aggregates multiple individual baselines into a single composite entity, allowing an administrator to scan and remediate a host or cluster against upgrades, patches, and extensions simultaneously in a single coordinated maintenance window.

Exam Rule (Baseline Group Composition): A Baseline Group can contain at most ONE Host Upgrade Baseline, combined with multiple Host Patch Baselines and multiple Host Extension Baselines. It is strictly forbidden to include more than one upgrade baseline within a single baseline group, as a host cannot be upgraded to multiple hypervisor releases simultaneously.

When a baseline group executes remediation, vSphere executes operations in a strict logical sequence: the Host Upgrade Baseline executes first, bringing the host to the target major ESXi version; subsequently, the Host Patch Baselines apply any incremental updates released after the upgrade ISO build; finally, the Host Extension Baselines inject third-party drivers and software packages.

Cluster Remediation Orchestration & Advanced Settings

Remediating a cluster using baselines requires coordinated orchestration to ensure that virtual machine workloads experience zero downtime. When an administrator initiates cluster remediation, vCenter presents an extensive suite of remediation and maintenance mode configuration options:

Maintenance Mode Orchestration & VM Migration

• DRS Integration: When vSphere DRS is enabled and operating in Fully Automated mode, DRS automatically issues vMotion migration tasks to evacuate all active, powered-on virtual machines to other hosts in the cluster before the target host enters maintenance mode.
• Handling Powered-Off and Suspended VMs: By default, powered-off and suspended virtual machines remain on the host when it enters maintenance mode if their disks reside on shared datastores. However, administrators can configure the option to "Migrate powered-off and suspended virtual machines to other hosts in the cluster." If a powered-off VM resides on local non-shared storage, the host will fail to enter maintenance mode unless the VM is relocated or an override is specified.
• Fault Tolerance (FT) Virtual Machines: For VMs protected by vSphere Fault Tolerance, secondary VMs can cause maintenance mode delays. Administrators can configure remediation to temporarily suspend or turn off Fault Tolerance on protected VMs during host remediation, restoring FT redundancy once the host returns to service.
• Retry Count and Delay: If a host cannot enter maintenance mode, for example because a VM will not migrate, vLCM retries based on the configurable retry delay and number of retries in the remediation settings instead of failing the whole task immediately.

Cluster Services Overrides During Remediation

To prevent cluster infrastructure services from inadvertently blocking rolling remediation, two critical overrides must be understood:

1. Temporarily Disable Distributed Power Management (DPM): vSphere DPM monitors cluster resource consumption and automatically places underutilized ESXi hosts into standby (powering them off via IPMI/iLO/Wake-on-LAN) to conserve power during low-demand periods. During rolling remediation, standby hosts must be awakened so that the cluster has maximum available compute capacity to absorb VMs evacuated from remediating hosts. If DPM remains active, it may attempt to power down hosts while remediation is attempting to migrate workloads. Enabling the override temporarily suspends DPM until all cluster hosts are remediated.

2. Temporarily Disable vSphere HA Admission Control: vSphere High Availability (HA) Admission Control enforces strict resource reservations (e.g., reserving 25% of cluster CPU and memory) to guarantee that surviving hosts can recover workloads in the event of a catastrophic host failure. When an ESXi host enters maintenance mode during rolling remediation, total active cluster capacity temporarily drops. If the remaining hosts cannot satisfy the configured HA admission control policy while absorbing evacuated VMs, HA admission control will actively block vMotion migrations or prevent the host from entering maintenance mode. Temporarily disabling admission control allows rolling remediation to proceed through the temporary capacity dip, automatically re-enabling enforcement once the cluster is fully updated.

Architectural Comparison: Baselines vs. vLCM Single Images

The architectural evolution from baseline-based patching to vLCM cluster images reflects a fundamental industry shift from imperative configuration management to declarative desired-state infrastructure. Enterprise architects and administrators must evaluate both approaches when designing lifecycle strategies.

Migration Procedure: Converting Baselines to a vLCM Single Image

Migrating an existing cluster from legacy baselines to a vLCM cluster image is executed through a structured, multi-step workflow in the vSphere Client:

1. Hardware Validation: Verify that all hosts in the target cluster share the same physical server vendor and architecture, and that all physical network and storage adapters appear on the VMware Compatibility Guide for the target ESXi release.
2. Initiate Image Setup: In the vSphere Client inventory, select the cluster, navigate to the Updates tab, select Image, and click Switch to Image (or Setup Image).
3. Assemble Desired Image:
   • Select the target Base ESXi Image version from the vCenter depot.
   • Select the matching OEM Vendor Add-on corresponding to the server hardware (e.g., Dell, HPE, Cisco).
   • Add any required Custom Components (such as specialized async drivers or NVIDIA vGPU software).
   • If third-party server management integration is deployed, associate the Hardware Support Manager (HSM) package.
4. Run Image Validation: Click Validate. vLCM performs a comprehensive dependency analysis to ensure that no conflicting VIBs exist between the layers and that no installed packages on the hosts will be orphaned.
5. Acknowledge Conversion Dialog: Click Save. vCenter displays a critical confirmation warning emphasizing that converting this cluster to an image specification is permanent and irreversible. Confirm the action.
6. Compliance Check & Remediation: Run an initial compliance scan against the new cluster image, stage payloads across the hosts, and initiate rolling cluster remediation.

Exam Trap: What happens to custom third-party VIBs (such as an old backup agent VIB or uncertified storage driver) currently installed on an ESXi host when the cluster is converted to a vLCM single image? If those VIBs are not explicitly defined in the Custom Components layer of the new image specification, vLCM treats them as unauthorized software drift and removes them from the host during remediation! Always inventory installed third-party VIBs using esxcli software vib list before transitioning to an image.

Upgrading VMware Tools and VM Hardware with vLCM (Objective 5.9.1)

vSphere Lifecycle Manager also upgrades virtual machines, not just hosts. Select a host or cluster and open Updates > VMware Tools or Updates > VM Hardware:

Follow these rules:

• Upgrade VMware Tools before VM hardware. The newer virtual hardware may need drivers that only the newer Tools provide.
• Take a snapshot or have a backup first. A VM hardware upgrade cannot be undone by simply lowering the version, and vLCM offers rollback options when you schedule the upgrade.
• Guest-managed Tools are skipped. VMs running open-vm-tools from the Linux distribution show as guest managed and are updated through the OS package manager, not through vLCM.
• Remember that a higher hardware version prevents the VM from running on older ESXi hosts, which matters for mixed-version clusters and DR sites.

Exam Trap: "Update virtual machines" in the vLCM objective means VMware Tools and VM hardware compatibility. Guest OS patching is outside vSphere Lifecycle Manager.