An ESXi 8.0 GA VM can report “Virtual NUMA cannot be configured when CPU hotadd is enabled” even when it has only one vNUMA node. Broadcom documents a configuration-validation problem involving virtual hardware 20, an ACPI motherboard layout, CPU Hot Add and a PCI passthrough device after a power cycle. Do not assume the message proves that the VM has crossed a physical NUMA boundary. A07-S2
This is a narrowly scoped, inspection-only diagnostic. No reconfiguration, reboot, device removal or performance test was executed. ESXi 8.0 GA means 8.0.0 and predates U1; U2/U3 incidents fall outside the confirmed GA case. The vendor’s stated U1 fix and conflicting 8.0.2 environment entry are both recorded below, without claiming a confirmed later-build remedy.
Why the error is surprising
Virtual NUMA describes the topology presented to a guest. CPU Hot Add is a separate capability for changing CPU allocation while a VM is running. Their interaction varies with platform and VM configuration; a general performance recommendation does not explain every validation error.
In this particular case, Broadcom attributes the conflict to the combination of PCI passthrough and the ACPI motherboard layout making the VM appear NUMA-enabled to the relevant validation path. The KB explicitly says the issue can occur without crossing physical NUMA boundaries and with only one vNUMA node. A07-S2
That observation changes the investigation. Counting the guest's nodes and concluding “there is only one, so this cannot be the documented issue” would discard the relevant explanation.
Match all documented conditions
Prerequisites are the failed reconfiguration task, the host build at that time, existing VM configuration and power-event history. Use authorised read access or existing support captures. Do not power-cycle the VM to manufacture the sequence.
Compare the evidence against the documented combination:
| Condition | Evidence to retain |
|---|---|
| ESXi 8.0 GA diagnostic scope | Exact incident-time host build |
| Virtual hardware 20 | VM compatibility/version record |
| ACPI motherboard layout | Existing VM configuration evidence |
| CPU Hot Add enabled | Current or incident-time CPU setting |
| PCI passthrough device configured | Device type and attachment record |
| A power cycle since configuration | Existing power/task timeline |
Broadcom lists DirectPath I/O, SR-IOV and vGPU as examples of the PCI passthrough condition. Record the actual device and supported combination; do not assume every virtual NIC or graphics adapter satisfies it.
If the motherboard-layout evidence is unavailable in the ordinary view, leave that condition unknown and request the approved support capture. Do not edit VM configuration files to discover what the setting does.
ESXi 8.0 GA means 8.0.0 and predates U1. An incident on U2/U3 is outside this article’s confirmed GA case. Use the existing VM configuration and support records for hardware version, CPU Hot Add and passthrough evidence; this article does not claim a newly verified UI/API collection route. Leave inaccessible layout or setting evidence unknown.
Work through a matching case
Imagine an invented hardware 20 VM on an 8.0 GA host. Its saved configuration shows ACPI layout, CPU Hot Add and a passthrough device. The task history shows a power cycle after those settings were established, followed by the exact reconfiguration error.
The guest reports only one vNUMA node. That does not contradict the documented case. The useful conclusion is that the configuration combination matches the known validation failure, rather than that the guest needs more NUMA nodes or the physical host needs different CPU placement.
If the VM instead has no passthrough device, do not force the diagnosis. The message may still require investigation, but the full documented combination is absent. Preserve the exact failure and configuration for a different explanation.
A later migration also matters: record the incident-time host, not merely the host that currently owns the VM. Otherwise the version comparison can be wrong even when the VM identity is correct.
Keep the remedy separate from the diagnosis
KB 318513 states that this issue is “resolved in VMware vSphere ESXi 8.0 U1 (build number 21495797)”. Its environment list nevertheless includes 8.0.2 as well as 8.0.0. Preserve both statements: the listed fix is vendor guidance, while applicability to a later-build incident remains unresolved. For an 8.0 U1-or-later host with the same error, obtain build-specific support confirmation rather than assuming the GA diagnosis or promising that a particular upgrade will fix it.
The KB also describes disabling CPU Hot Add as a workaround. That is a VM configuration change, not an observation. It can affect the intended operating model and belongs in a separately reviewed maintenance plan. This article does not supply an executable workaround or instruct an administrator to remove a passthrough device.
Resolve the exact corrective path against the current vendor guidance and the VM's device/guest support requirements before changing anything. A matching error string alone is insufficient to approve an upgrade or compatibility change.
Acceptance and reversal limits
The diagnostic result names the exact error, host build, VM hardware version, device/layout combination and event sequence. It records missing conditions and explicitly separates the source-cleared explanation from unresolved corrective-release advice.
After a qualified correction, proposed acceptance would include the intended reconfiguration succeeding and the passthrough workload retaining its required functionality. No such result is claimed here.
Inspection requires no rollback. A future CPU-setting, device or platform change needs a validated return plan; reverting a display setting is not necessarily sufficient to restore a device-dependent workload.
Learning notes
- One vNUMA node does not rule out this specific validator problem.
- Match the complete configuration and event sequence.
- A documented symptom does not resolve contradictory fix-version evidence.