VMware vSphere 8 Live Patching: Update ESXi Hosts Without Maintenance Mode or vMotion – ITFROMZERO

Table of Contents

The Real Problem with ESXi Cluster Patching

I manage a VMware cluster with 8 ESXi hosts at work, and every time VMware releases a security patch, the whole team breaks into a cold sweat. The standard procedure used to be: migrate all VMs to other hosts via vMotion, put the host into Maintenance Mode, install the patch, reboot, wait for the host to come back up, then migrate the VMs back. With 8 hosts, each patching cycle takes 4–6 hours — not counting the risks involved in migration.

The problem gets even worse in certain scenarios:

Hosts don’t have enough resources to absorb VMs from the host being patched
“Pinned” VMs that can’t be migrated (GPU passthrough, SR-IOV, USB passthrough)
Customers requiring 24/7 uptime with zero tolerance for downtime, even a few minutes
Emergency zero-day patches that need to be deployed immediately during business hours

Why Traditional ESXi Patching Takes So Long

ESXi is a bare-metal hypervisor — it runs directly on hardware. When patching, most updates need to overwrite kernel modules that are actively in use. You can’t “hot-swap” a kernel module while VMs are running, so a full system reboot is the only option.

A full hardware reboot of an ESXi host typically takes 10–15 minutes, plus:

vMotion migrating VMs out: 10–30 minutes depending on VM count and RAM size
Waiting for the host to enter Maintenance Mode: 2–5 minutes
vMotion migrating VMs back: 10–30 minutes

That’s 30–60 minutes per host — multiply by 8 hosts and you’ve lost an entire morning.

Available Approaches

Option 1: Maintenance Mode + Full Reboot (the old way)

This is the classic approach. Use vSphere Lifecycle Manager or esxcli to install the patch, then reboot:

# Check VIBs currently installed on the host
esxcli software vib list | grep -i vmware

# Install patch from offline bundle
esxcli software vib update -d /vmfs/volumes/datastore/patch.zip

# Reboot host after installation
reboot

The drawbacks are obvious: still requires Maintenance Mode, still requires a reboot, still causes downtime for VMs that can’t be migrated.

Option 2: Quick Boot (ESXi 6.7+)

VMware introduced Quick Boot in ESXi 6.7. Instead of a full hardware reboot (POST, BIOS, disk scan), Quick Boot only restarts the ESXi kernel layer — roughly 50–70% faster than a full reboot.

# Check whether Quick Boot is supported
/usr/lib/vmware/loadesx/bin/loadESX.py --check
# Expected output: quickboot: supported

# Enable Quick Boot
vim-cmd hostsvc/quickboot/enable

# Check status
vim-cmd hostsvc/quickboot/status

Maintenance Mode is still required, but reboot time drops from 15 minutes down to 4–6 minutes.

Option 3: VMware vSphere 8 Live Patching — No Maintenance Mode Required

This is the feature I’d been waiting for in vSphere 8. Live Patching allows certain types of patches — particularly security patches and critical bug fixes — to be applied without putting the host into Maintenance Mode and without migrating VMs.

How it works: vSphere 8 uses kernel live patching technology (similar to kpatch on Linux) — patches are injected directly into the running kernel’s memory, replacing specific functions without restarting any processes.

The Best Approach: Deploying Live Patching with vSphere 8

Prerequisites

vSphere 8.0 Update 1 or later — both vCenter and ESXi hosts must be on vSphere 8
License: vSphere Enterprise Plus or vSphere+ (Live Patching is not available in Standard)
Hardware listed on VMware’s Hardware Compatibility List (HCL)
Cluster configured with vSphere Lifecycle Manager (vLCM) in Image mode

Step 1: Check Whether the Host Supports Live Patching

# SSH into the ESXi host
# Check version
vmware -v

# Check Live Patching capability
esxcli software component list | grep -i livepatch

# View detailed platform information
esxcli hardware platform get

# PowerCLI from workstation — check the entire cluster
Connect-VIServer -Server vcenter.company.com

$cluster = Get-Cluster -Name "Production-Cluster"
Get-VMHost -Location $cluster | Select Name, Version, Build | Sort Name

Step 2: Ensure the Cluster Uses vLCM Image Mode

vLCM has two modes: Baselines (legacy) and Image (new). Live Patching only works with Image mode:

Open vSphere Client → select the Cluster
Go to the Updates tab → vSphere Lifecycle Manager
If you see “Manage with a single image” → you’re already in Image mode (good to go)
If it shows Baselines → you need to migrate to Image mode before using Live Patching

# PowerCLI: Check whether cluster is using Image or Baselines mode
$clusterView = Get-Cluster "Production-Cluster" | Get-View
$clusterView.ConfigurationEx.VsanConfigInfo

Step 3: Check Compliance and Confirm Patch Supports Live Install

vLCM automatically analyzes which patches can be applied live and which require a reboot. I typically use PowerCLI to get a full overview beforehand:

# PowerCLI: Check compliance across the entire cluster
$complianceResult = Test-Compliance -Entity (Get-Cluster "Production-Cluster")

# See which hosts are Non-Compliant
$complianceResult | Where-Object {$_.Status -ne "Compliant"} |
  Select Entity, Status

# View details: which patches support live install vs. require reboot
$complianceResult | ForEach-Object {
    Write-Host "Host: $($_.Entity.Name)"
    $_.PatchResults | Select PatchName, LiveInstall, RequiresReboot
}

Step 4: Apply the Live Patch via vSphere Client

This is the execution step. Follow this order carefully to avoid accidentally applying a reboot-required patch to production:

Navigate to Cluster → Updates → vSphere Lifecycle Manager
Click Check Compliance — wait 2–3 minutes
Select a Non-Compliant host → click Remediate
In the Remediation window, review the “Remediation Impact” section
If the patch supports Live Patching, you’ll see the option “Apply patches without reboot (Live Patching)” — check this box
Click Remediate to begin

# On the ESXi host, monitor live patch progress via log
tail -f /var/log/esxupdate.log

# View successfully applied live patches
esxcli software vib list | grep -i patch

While Live Patching is in progress:

The host does not enter Maintenance Mode
VMs are not migrated or restarted
Patch application time: 2–5 minutes depending on patch size
vCenter continues to show the host as online with VMs running normally

Step 5: Verify After Patching

# SSH into the ESXi host, confirm the version has been updated
vmware -v

# Confirm VMs are still running normally
esxcli vm process list

# Review the log to confirm no errors
cat /var/log/esxupdate.log | tail -30

# PowerCLI: Verify compliance after remediation
Test-Compliance -Entity (Get-Cluster "Production-Cluster") |
  Select Entity, Status, LastCheckedTime

Lessons Learned from 6 Months of Real-World Use

From hands-on experience running an 8-host cluster, here are a few practical things worth knowing:

Not every patch supports Live Patching: VMware Release Notes for each patch clearly state “Supports Live Install: Yes/No”. Major version updates (8.0 → 8.0 U2) always require a full reboot.
Critical security patches typically support Live Patching: This is the primary use case — apply CVE patches quickly with zero downtime.
Scheduled maintenance windows are still necessary: Live Patching handles minor patches, but major updates still require a reboot. I schedule quarterly maintenance windows for large updates.
Monitor for 30 minutes after patching: Even without a reboot, I keep the habit of watching the cluster after a Live Patch — tools like VMware Skyline Health are invaluable here for catching any anomalies before they escalate.
Always test on non-prod first: Fast and convenient as it is, always test on a dev/staging cluster before rolling out to production — this is a non-negotiable rule.

Live Patching in vSphere 8 has genuinely changed how I work. What used to take half a day and had to be scheduled outside business hours is now something I can handle in 5 minutes in the middle of the workday without anyone noticing — especially for VMs using GPU passthrough or SR-IOV that previously had to be shut down every time we patched the host.