What is the difference between vLCM Desired Image vs vLCM Baseline?

July 08, 2021

The vSphere lifecycle manager (vLCM) was first introduced with vSphere 7.  It is built into vCenter Server natively, making it easy to set up and configure. The vLCM is the path forward and it is intended to replace VMware Update Manager (VUM) in near future. If you are familiar with VUM then it provided the capabilities to create an upgrade baseline to upgrade the ESXi host. With the introduction of vLCM, we have introduced a new method that is ‘vLCM Desired Image‘ to upgrade the ESXi hosts.

The vLCM desired image method has few pre-requisites and one of such pre-requisites is that the vCenter Server and ESXi host has be on version 7 or above. Now, with this pre-requisite, you will not be able to upgrade the ESXi host which is lower than 7.0. Keeping these pre-requisites in mind, we have retained the baseline method and extended it to vLCM.

With vLCM, you can either remediate the ESXi host via vLCM Baseline (Same as VUM) or via vLCM desired state image (New remediation method). In this blog post, I will explain the differences between the vLCM Desired Image vs. Baseline.

Baseline

A baseline is a grouping of multiple bulletins like patch, extension, or upgrade binaries. Upgrade baseline contains the ESXi image, and patch baseline contains the respective patches for ESXi Host. You can check the compliance of the host against the associated baseline. 

vLCM Desired Image

The vLCM Desired Image is a new way of remediating the ESXi host, introduced in vLCM. The vLCM desired image is a declarative way of defining the ESXi host image. It is a cluster-centric feature that means you can configure and define the vLCM desired image at the cluster level only. All the ESXi hosts that are part of the vLCM enabled cluster will adhere to the desired image. 

The vLCM Desired Image has three main constructs.  

  • Base Image – The base Image allows you to define the ESXi host version

  • Vendor add-ons and components – Additional components and vendor add-on that you might want to install on the ESXi hosts.

  • Firmware and driver – This allows you to specify full-stack firmware versions provided by your hardware vendors.

image 104

vLCM Baseline vs. vLCM Desired Image

Let’s discuss some of the differentiating factors between these two remediation methods.

 

vLCM Desired State Image

vLCM Baseline

Declarative Lifecycle Management

Yes

No

ESXi Upgrade

Yes

Yes

Vendor Add-on

Yes

Yes, Manual with Custom ISO

Full-Stack Firmware Upgrade

Yes

No

VMware Solution Support
(vSAN, NSX-T, vSphere with Tanzu)

Yes, Fully integrated

Yes, Manual

vSAN HCL checks

Yes

No

UMDS Shared repository

Yes

Yes

Depot Override

Yes

No

Quick Boot Support

Yes

Yes

Suspend to Memory

Yes

No

Suspend to Disk

Yes

Yes

Automatically Downloads

Yes

No, Manually import the ISO to create the baseline

 

Declarative Lifecycle Management

With the baseline method, you need to import the ESXi ISOs to create the baseline. At times, you build the custom ISOs and may end up managing multiple ISOs. Contrary to this, the vLCM desired image provides you a declarative way of specifying the desired state. Define what you need in a cluster and vLCM will download the required resources (ESXi Base Image, Vendor Add-on, and Firmware and drivers) from the image depot. Downloading and importing the ISO images are not required in the case of the vLCM desired image.  

Full-Stack Firmware Upgrade

The vLCM is a plug-in-based model that allows Original Equipment Manufacturers (OEMs) to integrate with vLCM. You can leverage the vLCM desired image to remediate the ESXi host version and the firmware version together. The baseline method is not capable of remediating the full stack firmware and driver version.

As of today, with vSphere 7 Update 2, The following OEM vendors Dell, HP, Lenovo, and Hitachi have integrated their solutions with vLCM.

image 103

VMware Solutions and the vLCM integration

vSAN, vSAN File Service, NSX-T, and vSphere with Tanzu are among the supported solutions that means that you can deploy these solutions on a cluster managed by the vLCM desired image. It is important to note that when you enable a solution for a cluster that uses a vLCM desired image, the solution automatically uploads an offline bundle into the vSphere Lifecycle Manager depot and adds its component to all hosts in the cluster.

Now, vLCM takes care of the desired state of all the ESXi hosts. Any drift in the desired state is flagged by vLCM and you can remediate the ESXi hosts.

For example, If you deploy vSphere with Tanzu on a cluster managed by vLCM desired image then the spherelet vibs and other components are uploaded to vLCM desired image and vLCM remediates the ESXi hosts. 

The baseline approach still allows you to remediate the ESXi hosts with any of the VMware solutions. However, it cannot identify the drift related to other VMware solutions as it has no visibility of these solutions at all.

vSAN HCL Checks

The vLCM introduced hardware compatibility checks for vSAN storage I/O controllers, making life easier. It checks if the used firmware/driver combination is a supported combination yes or no. Currently, only vSAN storage I/O controller checks are available for HCL checks. It is important to note that you cannot view the HCL checks if you are managing the vSAN cluster with a baseline approach.

image-20210708234412-9

Shared UMDS repository

Both vLCM desired image and baseline method supports shared Update Manager Download Service(UMDS) repository. If you do not want the vCenter server to reach out to the VMware Online repository then you can set up a UMDS appliance that will download the updates on the behalf of vCenter server. The UMDS appliance can also be shared across multiple vCenter Servers in the environment.

image-20210708234412-10

           

Depot Override

Instead of accessing the vSphere Lifecycle Manager depot in vCenter Server, clusters in Remote Office and Branch Office (ROBO) deployments can download data from a depot that is local for them. You can configure vSphere Lifecycle Manager to use local depots for any cluster that uses images.

A ROBO cluster is a cluster that has limited or no access to the Internet or limited connectivity to the vCenter Server. As a result, clusters in ROBO deployments might have limited access to the vSphere Lifecycle Manager depot during the compliance check, remediation pre-check, and remediation operations.

With vSphere Lifecycle Manager images, you can use a local depot for ROBO clusters and configure vSphere Lifecycle Manager to use the local depot during the compliance check, remediation pre-check, and remediation tasks. The local depot overrides the vSphere Lifecycle Manager depot. Using local depots with ROBO clusters saves time and network bandwidth.

image 105

 

Suspend to Memory

Suspend-To-Memory (STM) is a new option that suspends the VM states into localhost memory during upgrades/remediation. Once the host is upgraded and the VMkernel is restarted using Quick boot, the VM’s are unsuspended and continue to run as they did before. Suspend to memory builds upon the Quick boot (requirement) feature that was released with vSphere 6.7. Please note that this option is only available if you are remediating ESXi hosts via the vLCM desired Image.

Suspend to memory feature can be useful in the environments like Test/Lab/Non-Prod where you can tolerate the downtime in return for faster upgrade cycles.

image 102

Parallel Remediation

The vLCM desired image can remediate 64 clusters in parallel and within the cluster, it remediates only one host at a time. There is a workaround to this, if there are multiple ESXi hosts which are in maintenance mode within the same cluster then vLCM will can remediate such hosts in parallel.

The baseline approach gives you the ability to remediate the ESXi hosts in parallel.

ISO and Image depot

As explained earlier, the vLCM desired image is a declarative model. You are only required to define a base image, vendor add-ons, and firmware and driver packages to construct a vLCM desired image. The vLCM will take care of importing all the constructs that are required for the vLCM desired image. Contrary to this, you need to manually import the ESXi ISO or Custom ISO to create a baseline. The vLCM desired image eliminates the efforts of downloading and uploading the required ISO. By default, The VMware image depot URL is up to date can be used by vLCM to set the desired image.

Stateful Install

It is important to note that vLCM desired image remediation requires a stateful installation which means that ESXi should be installed on a disk. Please consider migrating to stateful installation If you have a stateless ESXi host. Check out the details here. 

Conclusion

The vLCM desired image is the way forward as it is a declarative and cluster-centric remediation method. Having said that baseline method is still available and fully supported so that you can continue to upgrade your environment from 6.x to 7.0. Once you are on vSphere 7.0, then you can leverage the vLCM desired image method to manage the lifecycle of ESXi hosts.

References

vSphere 7 – Lifecycle Management 

The Virtually Speaking Podcast

Filter Tags

Lifecycle Management ESXi 7 vSphere 7 vSphere Lifecycle Manager (vLCM) Blog Deep Dive Overview Intermediate Deploy Manage

Jatin Purohit

Read More from the Author

Jatin Purohit is a Sr Technical Marketing Manager working with VMware. In the current role, Jatin focuses upon core vSphere and PowerCLI stuff. Connect via Twitter @jatinpurohit92