VMware Hotplug Memory and CPU: How to Enable, Configure, and Disable It Safely

VMware hotplug lets you add or remove vCPUs and RAM on a running VM without downtime. It’s essential for scaling production workloads that must stay online. This guide shows how to enable hotplug in vSphere, configure it per VM, and disable it when static allocation is required. You’ll get the exact steps, caveats, and best practices for safe resource scaling.

Why VMware Hotplug Memory and CPU Is Not Enabled by Default

Enabling CPU hotplug in VMware automatically disables vNUMA. This is not a bug but a deliberate trade‑off: administrators who don’t need live scaling would otherwise pay a permanent performance penalty. By default, VMware prioritizes performance and NUMA awareness over flexibility, leaving hotplug disabled until explicitly required.

How vNUMA Works and Why It Matters

NUMA (Non‑Uniform Memory Access) reflects physical hardware topology: each CPU socket owns local memory banks, and cross‑socket access is slower. vNUMA exposes this topology to the guest OS, allowing its scheduler to place threads near their memory. Minimum requirements: at least 4 vCPUs and 2 cores per NUMA node on the ESXi host.

What Happens to vNUMA When You Enable VMware CPU Hotplug

With CPU hotplug enabled, ESXi forces UMA (Uniform Memory Access). The guest OS sees one flat memory domain, ignoring physical topology. For small VMs (<8 vCPUs), this impact is minor. For large VMs (databases, SAP HANA, application servers), loss of NUMA awareness causes remote memory latency and throughput degradation.

vNUMA vs. UMA — Impact by VM Size

Memory Hotplug and vNUMA: A Different Story

Memory hotplug does not disable vNUMA. Enabling only memory hotplug carries far fewer performance risks than CPU hotplug. This distinction is critical for admins making per‑VM decisions: CPU hotplug trades performance for flexibility, while memory hotplug is safer to enable in isolation.

Guest OS Support Matrix for VMware Memory and CPU Hotplug

VMware hotplug support depends not only on the OS version but also on the OS edition. For example, Windows Server Standard and Datacenter editions support CPU hotplug, while lower editions may not. Memory hotplug has broader support across all Windows Server generations, making it more universally available than CPU hotplug. Linux distributions generally support both CPU and memory hotplug, but kernel version and distribution policies can affect stability. Administrators must always verify edition‑level support before enabling CPU hotplug, as eligibility is not guaranteed by OS version alone.

Windows Server Guest OS Support Matrix

Connect-VIServer
        Get-VM -Name 
        $spec = New-Object VMware.Vim.VirtualMachineConfigSpec
        $spec.memoryHotAddEnabled = $true
        $spec.cpuHotAddEnabled = $true
        (Get-VM -Name ).ExtensionData.ReconfigVM_Task($spec)

        # Verification across all VMs
        Get-VM | Get-View | Select Name, @{N="CPUHotAdd";E={$_.Config.CpuHotAddEnabled}}, @{N="MemHotA

mem.hotadd = "TRUE"
            vcpu.hotadd = "TRUE"

mem.hotadd = "TRUE"
            vcpu.hotadd = "TRUE"

How to Disable VMware Memory and CPU Hotplug

Disabling hotplug requires the VM to be powered off. The reversal process is identical to enablement: uncheck the boxes in Edit Settings or set the VMX parameters to FALSE via PowerCLI or configuration file edits.

Method 1: Using the vSphere Client (GUI)

1. 1. Power off the VM.
2. 2. Right‑click the VM → Edit Settings.
3. 3. Expand CPU → uncheck Enable CPU Hot Add.
4. 4. Expand Memory → uncheck Memory Hot Plug.
5. 5. Click OK and power on the VM.

Method 2: Using VMware PowerCLI

Connect-VIServer
    Get-VM -Name 
    $spec = New-Object VMware.Vim.VirtualMachineConfigSpec
    $spec.memoryHotAddEnabled = $false
    $spec.cpuHotAddEnabled = $false
    (Get-VM -Name ).ExtensionData.ReconfigVM_Task($spec)

    # Verification
    Get-VM | Get-View | Select Name, @{N="CPUHotAdd";E={$_.Config.CpuHotAddEnabled}}, @{N="MemHotAd

Method 3: Editing the VMX Configuration File Directly

1. 1. SSH into the ESXi host.
2. 2. Navigate to the VM’s datastore directory.
3. 3. Edit the .vmx file and set:

mem.hotadd = "FALSE" vcpu.hotadd = "FALSE"

1. 4. Save and reload the VM configuration.

Method 4: Editing VMX Parameters via vSphere Client Advanced Settings

1. 1. Power off the VM.
2. 2. Go to VM Options → Advanced → Edit Configuration.
3. 3. Set:

mem.hotadd = "FALSE"
        vcpu.hotadd = "FALSE"

1. 4. Save and power on the VM.

Important: Any resources added while hotplug was active remain allocated until the VM is powered off and reconfigured. Hot removal of memory is not supported — once added, memory stays until a full reconfiguration.

When to Enable and When to Avoid VMware Memory and CPU Hotplug

Enable Hotplug When

• Workloads face unpredictable demand spikes (web servers, reporting engines, batch processors).
• Downtime carries a high business cost.
• Pre‑provisioning overhead is not feasible.
• Small VMs (<8 vCPUs) where vNUMA impact is negligible.

Do Not Enable Hotplug When

• Large database or application servers (SQL Server, Oracle, SAP HANA) that rely on vNUMA for throughput.
• VMs already spanning multiple NUMA nodes.
• Situations where resources can be provisioned upfront and downtime scheduled during a maintenance window.
• Fault‑Tolerant VMs.

Should You Enable VMware CPU Hotplug?

Diagnosing Hotplug and NUMA Problems on ESXi

Troubleshooting hotplug and NUMA issues requires direct inspection of ESXi logs and shell commands.

• Inspect NUMA configuration per VM Use the vmdumper tool to review NUMA topology in the VM’s vmware.log. This reveals how vCPUs are mapped to NUMA nodes.
• Verify NUMA node count and vCPU balance Run:

sched-stats -t numa-clients

This command shows the number of NUMA nodes and whether vCPUs are evenly distributed.

• Identify forced UMA state when hotplug is active Look for numaHost log entries such as:

numa: Hot add is enabled and vNUMA hot add is disabled, forcing UMA

This confirms that enabling CPU hotplug has disabled vNUMA, flattening memory topology.

• Spot unbalanced vCPU NUMA nodes Logs and sched‑stats output can reveal skewed vCPU placement, which leads to remote memory access latency and throughput loss.
• Mitigation strategy when hotplug cannot be disabled Configure vCPU and Cores per Socket = 1×1. This forces each vCPU to appear as a separate socket, reducing NUMA imbalance even under UMA conditions.

Virtual Machine File Recovery After Hotplug Misconfigurations and Failures

How Hotplug Changes Can Corrupt VM Files

Configuration errors during hotplug operations — abrupt power losses mid‑reconfiguration, failed VMX writes, or datastore I/O errors under memory pressure — can leave VMDK files inconsistent, corrupt VMFS metadata, or make a datastore inaccessible. Hotplug‑triggered memory spikes may also exhaust ESXi host memory, causing VM crashes that leave dirty disk images.

What Gets Damaged and Why Recovery Is Complex

VMFS structures such as the File Descriptor (FD), resource allocation bitmaps, and volume metadata are binary and not self‑healing. A corrupted VMFS volume can make all VMs on the datastore invisible even if the storage hardware is intact. VMDK descriptor files, flat extent files, and snapshot chains (.vmsd, .vmsn) are all vulnerable to corruption.

Recovering VMware Data with DiskInternals VMFS Recovery™

When hotplug‑related failures result in inaccessible VMs or corrupted datastores, DiskInternals VMFS Recovery™ provides a proven recovery path. It supports:

• VMFS volumes that fail to mount
• VMDK files unreadable by vSphere
• Corrupted ESXi datastore metadata
• VMFS volumes on failed or degraded RAID arrays
• Accidental deletion of VM files from datastores

The tool offers free file preview before purchase, allowing administrators to confirm recovery viability. It handles both physical drive failures and logical corruption — the exact failure modes triggered by misconfigured hotplug operations and unplanned ESXi crashes.

Best Practices for VMware Memory and CPU Hotplug in Production

• Audit before enabling — run sched-stats -t numa-clients to understand current NUMA topology before changing hotplug settings.
• Enable memory hotplug independently — memory hotplug carries no vNUMA penalty; use it selectively for scale‑up workloads.
• Reserve CPU hotplug for specific VMs — avoid applying it as a blanket policy across all VMs.
• Document initial resource allocations — record RAM and vCPU counts at VM creation; the 16× memory ceiling is calculated from the initial allocation.
• Test hotplug behavior in staging — confirm the guest OS recognizes newly added resources before enabling in production.
• Back up VM configurations before reconfiguring — export .vmx files and take snapshots before enabling or disabling hotplug.
• Monitor with vSphere performance charts — watch for memory latency increases and CPU ready spikes after enabling CPU hotplug on large VMs.
• Keep VMFS Recovery™ in your toolkit — datastore‑level failures from misconfiguration are recoverable with the right tooling.

FAQ