Why vLCM Live Patch Shows “Not Eligible” and How to Fix It

Resolve vLCM Live Patch “Not Eligible” errors with simple troubleshooting steps from our Server Management Support team.

Why vLCM Live Patch Shows “Not Eligible” and How to Fix It

vSphere Lifecycle Manager (vLCM) Live Patch and its difference from traditional ESXi remediation are discussed here. It also highlights a scenario where hosts show “Live Patch Not Eligible” during remediation, along with the possible causes behind it. A simple troubleshooting workflow and a few practical steps to reduce patching issues in production clusters are also included. Read the article to learn more.

What Makes vLCM Live Patch Different from Traditional Remediation

vSphere Lifecycle Manager (vLCM) Live Patch, introduced in vSphere 8 Update 3, permits certain ESXi security updates to be installed without rebooting the host. This helps in reducing the maintenance time, along with keeping workloads running during patching.

On the other hand, in traditional remediation, the host enters maintenance mode, VMs are moved to other hosts using vMotion, and the host must reboot after patching. This process is lengthier and temporarily reduces cluster capacity.

Live Patch ensures that virtual machines continue to function normally by applying qualified updates straight to the host. However, Live Patch only functions when the necessary conditions are met for hardware support, VM configurations, DRS automation, patch compatibility, and cluster configuration.

The Complex Issue: Although Live Patch is Enabled, Hosts Display “Live Patch Not Eligible,” and Remediation Fails

 

Live Patch may be enabled in vSphere Lifecycle Manager in certain scenarios, but it is not used by the patch process during remediation. Instead, for some hosts, the system can show “Live Patch Not Eligible.”

When this occurs, vLCM employs the conventional remediation technique. To finish the update, the host must go into maintenance mode, move virtual machines, and restart.

Some common signs of this situation include:

• Remediation starts, but Live Patch is not used
• In compliance results, hosts display “Live Patch Not Eligible.”
• Reboot-based remediation is the next step in the update process.
• After patching, some hosts are still only partially compatible.
• Certain virtual machines are designated as incompatible.

Root Cause (Most Common in Production)

 

Live Patch only functions in the cluster when specific requirements are fulfilled. The host will not be eligible for Live Patch if any of these conditions are not met, in which case the system will employ standard remediation.

• Patch Not Supported for Live Patch

Live patching is not meant for all ESXi updates. Certain updates change essential elements like the VMkernel or other low-level system modules, which still need to be rebooted in order to finish the installation.

• Cluster Image Differences

The ESXi base image, vendor add-ons, and drivers are some of the components used to set up clusters managed with vLCM image-based lifecycle management. Live Patch eligibility may be affected if certain elements are inconsistent between hosts or if there are unsupported add-ons.

• DRS Not Fully Automated

The Distributed Resource Scheduler (DRS) is used by Live Patch to control workloads while patching. The remediation process might not function as planned if DRS is not set up in Fully Automated mode or if restrictions restrict VM movement.

• Hardware-Level Limitations

Some hardware configurations can interfere with Live Patch operations. This may include passthrough devices, specialized hardware accelerators, or unsupported driver modules that require a reboot after updates.

• VM Configuration Restrictions

Certain virtual machine settings can also block Live Patch. Features such as Fault Tolerance, DirectPath I/O, PCI passthrough, vGPU usage, or shared disk clusters can prevent the suspend-resume behavior needed for Live Patch operations.

Technical Resolution: Step-by-Step Fix Workflow

 

To fix Live Patch problems, check a few things step by step. This helps find what is blocking Live Patch.

Step 1: Verify the Versions

Check vCenter Server and all ESXi hosts are running vSphere 8.0 Update 3 or later. Also, confirm that the hosts are connected to vCenter and working normally without errors.

Step 2: Verify Live Patch Enforcement

Navigate to Lifecycle Manager settings and ensure the Enforce Live Patch option is enabled in remediation configuration.

Step 3: Run a Cluster Compliance Scan

Perform a compliance check from Lifecycle Manager and review the eligibility details. This scan identifies hosts that are not eligible and highlights image mismatches or incompatible components.

Step 4: Review DRS Automation Settings

Ensure DRS is enabled and configured as Fully Automated. Review cluster rules and affinity constraints that may prevent workload migration.

Step 5: Check Hardware and Driver Compatibility

Inspect host hardware settings and confirm that passthrough devices, firmware versions, and vendor add-ons align with the approved ESXi build.

Step 6: Identify VM Configuration Restrictions

Locate virtual machines using unsupported features such as Fault Tolerance or DirectPath I/O. Consider migrating these workloads, scheduling a separate patch window, or temporarily disabling conflicting features if possible.

Step 7: Test Remediation on a Single Host

Before remediating the entire cluster, apply the patch to one host first. This controlled validation confirms whether Live Patch works correctly before continuing across the cluster.

Best Practices to Prevent Live Patch Failures in Production

 

Avoiding Live Patch issues mostly depends on good preparation and keeping the cluster properly configured. When hosts, drivers, and settings stay consistent across the cluster, Live Patch is more likely to work smoothly.

Some helpful practices include:

• All hosts should have the same ESXi image, drivers, and vendor add-ons.
• Turn DRS to Fully Automated to allow workloads to shift as needed.
• Patching virtual machines (VMs) with fault tolerance, passthrough devices, or vGPU should be planned individually.
• Keep the additional cluster capacity (N+1) so that workloads can change while updates are being made.
• To identify problems promptly, do compliance checks prior to the maintenance window.
• Make sure that firmware versions and vendor add-ons match the ESXi build.

Following these steps helps reduce patching problems and makes Live Patch more reliable in production clusters.

[Need assistance with a different issue? Our team is available 24/7.]

Conclusion 

Live Patch helps minimize disruption during ESXi updates, but it only works when cluster settings, hardware, and VM configurations meet the required conditions. When hosts show “Live Patch Not Eligible,” reviewing these factors usually helps identify the blocker.