VMware vSphere CPU Hot-Plug and Memory Hot-Add Support

Discover how to dynamically scale your VMs with additional RAM or CPU cores without shutting them down, even across mixed OS environments.

Imagine being able to add more CPUs or RAM to a busy server without ever turning it off. VMware vSphere’s CPU Hot-Plug and Memory Hot-Add features make this possible, allowing you to scale up virtual machines (VMs) on the fly with zero downtime. These capabilities have been around since ESXi 4.0, but they come with specific requirements and some important caveats.

In this article, we’ll explore how CPU Hot-Plug and Memory Hot-Add work, what you need to use them, and how different guest operating systems react to having resources added live. We’ll also discuss performance implications (like virtual NUMA considerations) and best practices to help you decide when to use these features.

Overview and Key Requirements

CPU Hot-Plug (often called CPU Hot-Add) and Memory Hot-Add are vSphere features that let you add virtual CPUs and memory, respectively, to a running VM without rebooting it. This is extremely useful for handling sudden workload spikes or performing upgrades in test environments without scheduling downtime. However, these features are disabled by default in vSphere due to the overhead and limitations they introduce. Before using Hot-Add/Hot-Plug, be aware of the following key requirements and limitations:

• Supported Virtual Hardware Version: The VM must be using virtual hardware version 7 or higher to enable hot-add/hot-plug. Newer versions are fine (vSphere 8.0 uses vHW 20), but anything below 7 will not have these options.
• vSphere Licensing: You need a vSphere edition that includes the Hot-Add feature. In older vSphere releases this meant Enterprise or Enterprise Plus licensing. (For example, vSphere 6.5/6.7 Standard did not allow hot-add CPU/memory without an Enterprise license.) In vSphere 8, the Standard edition does support hot-add features, so the requirement is effectively any non-Essentials licensing on modern versions. Always check the VMware product documentation for your version’s licensing details.
• Enable While Powered Off: You must power off the VM to turn on the Hot-Plug/Hot-Add capability. The feature can only be enabled through the VM settings when the VM is shut down. Once it’s enabled and the VM is powered on, you can add CPU or RAM dynamically. (If the VM is running and you find the CPU/Memory fields grayed out, it means hot-add is not enabled yet.)
• VMware Tools in Guest: Ensure that VMware Tools (or open-vm-tools for Linux) is installed in the guest OS for best results. While hot-plug may work on a supported OS without VMware Tools, having the tools installed improves the communication between ESXi and the guest, ensuring the new vCPU or memory is properly recognized.
• Not Compatible with Fault Tolerance: You cannot use CPU or memory hot-add on a VM that has VMware Fault Tolerance enabled. FT requires tight synchronization between primary and secondary VM, which doesn’t support changing CPU/RAM on the fly. If you need to hot-add resources, you’ll have to disable FT on that VM.
• Add-Only (No Hot-Remove): vSphere only supports adding vCPUs or memory while a VM is running – you cannot remove virtual CPUs or RAM on the fly. Once you hot-add a vCPU or some RAM, that resource remains allocated to the VM until it’s powered off and manually removed in the settings. In other words, hot-plugged CPUs and hot-added memory become a permanent part of the VM’s configuration (at least until the next reboot). This one-way street is for safety: most operating systems can handle new resources appearing but would not react well to resources vanishing unexpectedly.
• vNUMA Impact: Enabling CPU Hot-Plug has a significant side effect on large VMs: it disables virtual NUMA for that VM by default. vNUMA (virtual Non-Uniform Memory Access) is the feature that presents a NUMA topology to the guest OS for optimal performance on multi-socket hosts. When vNUMA is disabled, the guest OS sees all vCPUs as belonging to one NUMA node, which can lead to suboptimal memory access patterns in workloads that scale across multiple CPUs. Thus, turning on Hot-Add may incur a performance penalty for big VMs (more on that in the Performance section). Note: As of vSphere 8, this limitation has been partly addressed – there is a new advanced setting to expose vNUMA even with CPU Hot-Add enabled. It requires virtual hardware 20 and an API-only configuration, but it allows a VM to have multiple vNUMA nodes despite Hot-Plug being on. By default, however, unless you configure that, CPU Hot-Plug will hide the NUMA topology from the guest.
• Fixed vCPU Core-to-Socket Ratio: You cannot change the number of cores per socket for a VM while it is powered on. The core-per-socket setting (which influences vNUMA as well) is set at boot time. For example, if your VM was configured as 2 sockets x 4 cores each (8 vCPUs total), you can hot-add more vCPUs (if supported), but you can’t change it to 1 socket x 8 cores on the fly. You’d need to power off to alter the CPU socket configuration.
• Guest OS Support Required: The guest operating system itself must support CPU and memory hotplug for the feature to work fully. Enabling the option in vSphere is just one side of the equation – the OS inside the VM has to detect and use the added CPU/RAM. (In unsupported OSes, you might toggle the setting and vSphere will add a vCPU, but the guest won’t notice it, effectively wasting that virtual CPU until a reboot.) We’ll detail OS compatibility in the next section.
• Slight Guest Kernel Overhead: Some operating systems reserve a small portion of resources when hot-add is enabled, even if you don’t end up adding anything. For instance, Windows might set aside a bit of kernel memory (e.g. reducing the available paged pool) in anticipation of possible new memory being added. This overhead is usually minimal (on the order of a few percent or less of resources) and shouldn’t be a major concern, but it’s good to be aware that enabling hot-add isn’t completely “free.” It’s a trade-off for the flexibility.
• Memory Hot-Add Limits: There are a couple of constraints on hot-adding memory in vSphere. First, a design limitation is that you can only hot-add up to 16 times the initial configured memory of the VM. For example, if a VM starts with 4 GB RAM, you can grow it to a maximum of 64 GB via hot-add (16 × 4 GB). If you need to go beyond that, a power-off will be required to assign more memory. Second, on some older operating systems and 32-bit platforms, if the VM started with a very small amount of RAM (under 3-4 GB), hot-add might not work properly. VMware notes that VMs with ≤3 GB of initial memory can encounter issues – the guest OS might not detect the added RAM or might only allow expansion up to the 3 GB range. The recommendation in those cases is to initially provision more than 3 GB of memory if you plan to use hot-add, or else shut down and increase the memory the old-fashioned way.

Enabling Hot-Add in vSphere (How to Turn It On)

Before you can use CPU hot-plug or memory hot-add on a VM, you have to enable those settings. This can only be done when the VM is powered off. In vSphere Web Client or the vCenter UI, edit the VM’s settings and look under the VM Hardware section for CPU and Memory settings. You’ll find checkboxes for “Enable CPU Hot Add” (sometimes labeled CPU hot-plug) and “Memory Hot Add”. Tick the boxes for the resources you want to be able to add while the VM is running, then save the settings. Once you power the VM back on, it’s ready to accept added vCPUs or RAM on the fly.

Enabling CPU Hot-Add and Memory Hot-Add for a VM (vSphere Web Client example). You must shut down the VM to toggle these settings.

After enabling, adding resources is straightforward: in vCenter, you can adjust the number of virtual CPUs or the amount of RAM in the VM’s settings while it’s powered on. Upon applying the change, vSphere will hot-add the new CPU or memory to the live VM. Remember: the guest OS must support this for it to take effect immediately – otherwise, the new CPU/RAM might appear in vSphere but not be utilized in the guest until a reboot.

Also note that once the VM is running with Hot-Add enabled, the CPU and Memory fields in the hardware settings will be editable (no longer grayed out). If they remain uneditable while the VM is on, it means the feature isn’t enabled or something (like FT) is preventing it.

Guest OS Support and Behavior

Guest operating system support is the critical piece of the puzzle. Just because vSphere can add a CPU or memory stick to the virtual hardware doesn’t guarantee the OS will know what to do with it. Many modern OSes do support hot-add, but the behavior can differ. Let’s look at how various OS families handle CPU hot-plug and memory hot-add as of vSphere 8.0 U3:

Windows Server 2019 and 2022

Windows Server (especially recent versions 2019 and 2022) has excellent support for both CPU and memory hot-add. In VMware’s compatibility guide, Windows Server 2019 and 2022 (Standard and Datacenter editions) are fully supported for hot-add vCPUs and RAM. In practical terms, this means you can add CPUs or memory to a running Windows Server 2019/2022 VM and the OS will immediately recognize and use the new resources – no reboot needed.

In our tests and experience with Windows Server (2012 R2, 2016, 2019, 2022), the behavior is very smooth:

• When you hot-add one or more vCPUs, the Device Manager and Task Manager will detect the additional processors on the fly. You might need to click “Refresh” in Task Manager’s Performance tab or reopen it to see the updated CPU count. But the OS scheduler begins using the new CPUs right away. For example, if a VM had 4 vCPUs and you added 2 more, Windows will now show 6 CPUs available and spread workloads accordingly – all without interruption.
• When you hot-add memory (say increase from 8 GB to 12 GB), Windows will immediately show the higher amount of RAM in tools like Task Manager, System Information (systeminfo), or Resource Monitor. The extra memory is usable by applications right after it’s added. There’s no need to restart the VM; the Windows kernel handles the dynamic memory addition under the hood.

One thing to keep in mind is that historically, some lower-end editions of Windows Server did not support hot-add of CPU (for example, Windows Server 2008 R2 Standard allowed hot-add of RAM but not CPU). However, with Windows Server 2016 and newer, Standard and Datacenter editions both support CPU and RAM hot-add. Essentials editions generally also support it if the edition exists for that version (Windows Server 2022 has an Essentials edition which VMware lists as supported for hot-add). The older limitation of “you need Enterprise or Datacenter edition for CPU hot-plug” is no longer applicable in the 2019/2022 generation.

Tips for Windows guests: After hot-adding resources, you might notice that the VM’s NUMA topology option in vSphere (if you edit VM settings > CPU) is now grayed out; that’s because vNUMA was turned off when you enabled hot-add. This is expected (as mentioned earlier). Also, if you use any kind of resource limits or reservations on the VM (in the vSphere settings), be mindful that those might need adjustment. For example, if the VM had a memory limit of 8 GB and you hot-add memory to 12 GB, the limit could effectively cap it at 8 GB until you remove or raise the limit. This is a common “gotcha” – admins forget about a limit configured, and wonder why the OS doesn’t actually get to use the new memory even though it’s added.

What about Windows 10/11 or other editions? Hot-add of CPU and memory is primarily a server OS feature for Windows. Client versions like Windows 10 and Windows 11 do not support CPU hot-plug. So if you’re running a Windows 10 VM and try to hot-add a vCPU, vSphere might do it, but the OS won’t utilize that new CPU until a reboot (if at all). Generally, plan to use this on server-class OSes where it’s officially supported.

Linux: RHEL 9 / CentOS Stream 9 / Rocky Linux 9

Modern enterprise Linux distributions have had kernel support for CPU and memory hotplug for many years. Red Hat Enterprise Linux (RHEL) 9 and its derivatives (CentOS Stream 9, Rocky Linux 9, AlmaLinux 9, etc.) fall into this category and are officially compatible with vSphere’s hot-add features. VMware’s compatibility guide, for example, lists RHEL 9 and Rocky Linux 9 as supporting both hot-add memory and hot-add vCPU on vSphere 8.

In RHEL 9 family distributions, when you hot-add vCPUs or RAM, the OS will typically handle it automatically, with no manual intervention needed:

• CPU: The Linux kernel will detect the newly added CPU cores and auto-online them. In many enterprise distros like RHEL, there are udev rules or systemd services that ensure any hot-plugged CPU is brought online (made available for scheduling) immediately. So if your RHEL 9 VM had 2 vCPUs and you added 2 more, running lscpu or checking /proc/cpuinfo inside the VM would show the CPU count increase, and the system can schedule threads on the new CPUs right away. You might also see a kernel message in dmesg about CPU hotplug, but no user action is required.
• Memory: Similarly, hot-added memory is recognized and onlined by the kernel. RHEL by default enables memory hot-add auto-online. This means the moment you increase the VM’s RAM, the OS updates its available memory pool. You can verify by checking /proc/meminfo or running the free command – the total should reflect the new memory size without a reboot. The mechanism involves the kernel’s ACPI hotplug handler automatically onlining new memory blocks. In older days, some admins had to manually echo online to files like /sys/devices/system/memory/blockX/state, but RHEL 8/9 usually does this for you automatically.

The behavior described above has been observed in earlier RHEL/CentOS versions as well. For instance, with CentOS 7 and 8, CPUs and memory added via vSphere hot-add came online immediately thanks to Red Hat’s default configuration that includes auto-onlining. By 2024, with RHEL 9 and its clones, this “just works” nature continues. In summary, if you’re running a RHEL 9 or clone VM with VMware Tools (or the open-vm-tools package) installed, you can confidently hot-plug CPUs or RAM and the OS will make use of them on the fly.

Linux: Ubuntu 22.04 LTS and Debian 12

Ubuntu and Debian (which share a lot of upstream kernel behavior) also technically support CPU and memory hot-add at the kernel level, but the default behavior on these distributions is a bit different compared to RHEL. Ubuntu Server 22.04 LTS and Debian 12 (Bookworm) are both listed by VMware as supported guests for hot-plug features; however, if you try it, you’ll notice the resources don’t become available without some extra steps.

On Ubuntu/Debian, by default hot-added vCPUs start in an “offline” state in the guest OS, and hot-added memory remains unusable (offline) until onlined. In practice:

• CPU: When you add a vCPU to, say, an Ubuntu 22.04 VM, the kernel will detect the new CPU’s presence (you might see it in dmesg), but it won’t automatically bring it online. The new CPU core will be listed under /sys/devices/system/cpu/ (e.g. as cpu3 if it’s the 4th CPU), but if you check /proc/stat or top, it’s not being scheduled. You can manually online the CPU by executing a command like:

echo 1 | sudo tee /sys/devices/system/cpu/cpu3/online

(replace cpu3 with the appropriate CPU number for each new CPU). Once that is done, the CPU becomes active. Without doing this or rebooting, the added vCPU stays idle and ignored by the scheduler. In other words, Ubuntu/Debian require an admin action to start using hot-added CPUs.

• Memory: Likewise, if you increase an Ubuntu VM’s memory from e.g. 4 GB to 6 GB, the OS will still report 4 GB usable until you either reboot or manually online the new memory blocks. The additional memory is essentially in a “standby” state. You can bring the memory online by finding the new memory section in /sys/devices/system/memory/ and toggling it. Typically, a udev rule or manual step can set all new memory sections to online. For instance, running a loop like:

for d in /sys/devices/system/memory/memory*; do echo online | sudo tee $d/state; done

would bring all memory sections online (though one would usually target only the ones that are currently “offline”). By default, however, Ubuntu does not do this automatically. This means if you don’t take action, the OS will act as if the extra RAM isn’t there (even though vSphere added it). In effect, memory hot-add on Ubuntu/Debian without manual intervention requires a reboot to actually use the new RAM.

Why this behavior? It’s largely because Ubuntu/Debian choose not to auto-online for safety or simplicity, whereas RHEL/SUSE do auto-online. The good news is that this can be changed: advanced users can configure Ubuntu or Debian to auto-online hotplugged resources (for example, by adding appropriate udev rules or kernel boot parameters like memhp_default_state=online). But out-of-the-box, expect that “supported” means “it won’t crash, but you might need to reboot for it to take effect” on these distros. So VMware saying it’s supported is accurate in that the VM won’t be harmed by hot-add, but the admin has to do a bit more work to actually utilize the added CPU/RAM.

Bottom line: Ubuntu 22.04 and Debian 12 guests will let you toggle hot-add and even show the new CPU/Memory in vSphere, but to avoid a reboot you’ll need to manually online the resources. If a reboot is acceptable, then simply rebooting the VM after the hot-add will also cause it to see the new total CPUs/RAM (since on boot it will count everything).

Linux: SUSE Linux Enterprise Server 15 SP5

SUSE Linux Enterprise (SLES) is another enterprise distro that, like RHEL, handles hot-added resources gracefully. SLES 15 SP5 fully supports CPU hot-plug and memory hot-add and, by default, it will automatically online both new CPUs and new memory as they are added. VMware’s compatibility guide marks SLES 15 as supported, and our experience confirms that it works seamlessly:

• When you hot-add vCPUs to a SLES 15 SP5 VM, the OS immediately brings them online. The additional CPUs will appear in lscpu output and be utilized. There’s no manual step needed; SUSE’s default configuration (via systemd or udev) ensures that any new CPU is set to online=1 as soon as it’s detected. This behavior was also present in earlier SLES versions (for example, SLES 12 SPx), which have been known to accept hot-added CPUs without fuss.
• When you hot-add memory, SLES will recognize the new memory and add it to the available pool right away. Checking /proc/meminfo or running free -m will show the increased memory available. SUSE’s approach to hot-added memory is very user-friendly – it updates the system’s memory maps on the fly. In tests, even monitoring tools like top or graphical tools in SUSE would show the memory jump in real time, no restart of the tool needed.

Because of this immediate application of resources, SUSE is a great choice if you plan to frequently use hot-add to scale VMs up. It’s essentially “plug and play” in the guest. Just be sure you have the VMware Tools (or open-vm-tools) installed, which is usually the case in SLES since open-vm-tools often comes pre-installed or in SUSE’s package repositories.

FreeBSD 13 and 14

Not all operating systems are on board with the hot-plug revolution – FreeBSD is a key example of an OS that currently does not support CPU or memory hot-add in a running system. FreeBSD 13.x and 14 (which at the time of writing are recent stable branches) simply have no facility to dynamically add CPUs or RAM after boot. VMware’s compatibility listings for FreeBSD do not indicate support for these features, and empirical testing shows the same.

What happens if you try it anyway? Suppose you have a FreeBSD 13 VM and you enable CPU Hot-Plug in vSphere, then at runtime add another vCPU. vSphere will add the virtual CPU to the VM’s virtual hardware, but FreeBSD will ignore it until next boot. The additional CPU won’t show up in hw.ncpu (the system control that reports number of CPUs) or in top/htop. It’s as if nothing happened – because from FreeBSD’s perspective, its ACPI CPU hotplug handler isn’t doing anything. The CPU will only be enumerated when the VM boots up the next time. The same story applies to memory: you could hot-add memory to a FreeBSD VM, but dmesg won’t show any new memory, and the output of sysctl hw.physmem or vmstat will remain at the old value. The extra memory is essentially invisible to FreeBSD until a reboot causes the full hardware discovery to run again.

The positive news is that attempting a hot-add doesn’t crash or destabilize FreeBSD; it’s simply ineffective until reboot. So you’re not going to harm the running system by toggling the setting – you just won’t get the result you want. In short, FreeBSD 13/14 do not support CPU or memory hot-add at all. If you need to give a FreeBSD VM more resources, you’ll have to plan a maintenance window to shut it down, adjust the vCPU or RAM, and start it up again.

(It’s worth noting that other Unix-like OSes have similar limitations. For example, older Solaris versions on x86 also didn’t support hot CPU/memory add in a VM. Always check the VMware Compatibility Guide if you’re unsure about a particular OS.)

Performance Impact and Best Practices

Hot-adding CPU and memory is wonderfully convenient, but it’s not a silver bullet – there are performance considerations and best practices to keep in mind. VMware doesn’t enable these features by default precisely because they can have downsides if used indiscriminately.

vNUMA and Performance

The biggest impact of enabling CPU Hot-Add is the loss of vNUMA awareness by default (again, unless you use the new vSphere 8 advanced setting). For small VMs (say 4 vCPUs or less, fitting in one NUMA node), this won’t matter. But for larger VMs that span multiple NUMA nodes (typically 8 vCPUs or more, or any VM configured with more vCPUs than a single physical NUMA node has cores), having vNUMA disabled can hurt performance. The guest OS and applications won’t “know” the NUMA topology, so they might make poor scheduling and memory placement decisions – e.g. a thread might allocate memory that’s actually on a remote NUMA node, incurring higher latency, because the OS thinks it’s a uniform memory architecture.

VMware’s Performance Best Practices guide recommends leaving CPU Hot-Add off unless you truly need it. And for good reason: in an internal test, VMware found that a large VM (28 vCPUs, running a database workload) performed 2% to 8% better with CPU Hot-Add disabled compared to when Hot-Add was enabled. The difference was attributed to vNUMA optimization – with Hot-Add off, the VM had a proper dual NUMA node presentation and the database could optimize for it, whereas with Hot-Add on, the guest saw a single NUMA node and incurred more cross-node memory traffic. The takeaway: if you have a very CPU-intensive or NUMA-sensitive application (like a large database or scientific workload), think twice about using Hot-Add, as it may subtly reduce performance. If you anticipate needing more vCPUs, another strategy is to size the VM with the maximum vCPUs from the start (though having a bunch of unused vCPUs also has a small overhead and can confuse some OS schedulers too).

The new vSphere 8 capability to allow vNUMA with Hot-Add might mitigate this issue in the future. If you’re on vSphere 8 and comfortable using the API or advanced settings, you can experiment with enabling exposeVnumaOnCpuHotadd to have the best of both worlds: flexibility to add CPUs and keeping vNUMA. Just remember it’s a relatively new feature (as of late 2022) and requires the latest virtual hardware and OS support for NUMA.

General Overheads

Aside from vNUMA effects, simply having Hot-Add enabled on a VM incurs a slight overhead on the ESXi host and possibly the guest. The hypervisor has to maintain some extra accounting for the “potential” resources. For example, when memory Hot-Add is enabled, ESXi might reserve a bit more overhead memory for that VM to accommodate the maximum memory you could hot-add. Similarly, the guest OS, as mentioned, might reserve some structures for new memory or CPUs. These overheads are generally small – typically a few percent or less impact on resources. A VMware community forum post confirmed that there isn’t a known significant performance penalty for simply enabling memory hot-add by itself (and it does not disable vNUMA if CPU hot-add is off). So enabling memory hot-add alone is relatively benign performance-wise. CPU hot-add, however, is the one you should be cautious with due to vNUMA and scheduling implications.

Best Practices – Use Only When Needed

VMware experts often advise that you do not enable Hot-Add on every VM by default. Instead, treat it as a tool for specific scenarios. There are a couple of reasons for this philosophy:

• Predictability: If you size your VMs properly from the get-go (based on capacity planning or anticipated load), you shouldn’t often need to add resources on the fly. By not enabling hot-add everywhere, you ensure that big VMs get the vNUMA benefit and you avoid any minor overhead on VMs that will never need it. Essentially, don’t trade away performance for a convenience you won’t use.
• Change Management: In some environments, suddenly adding CPUs or RAM to a VM can have licensing implications (for software running inside, like databases that license per-core, or Windows Server licensing which might count cores for activation in some cases). It can also affect cluster capacity planning (e.g. if a bunch of VMs all hot-add RAM, you might risk ballooning or swapping if the host isn’t actually equipped to handle the new total allocation). So, it’s something to use deliberately, not haphazardly.
• Troubleshooting and Monitoring: VMs with hot-add enabled can be harder to track in inventory – there’s no obvious flag in the vCenter UI unless you dig into each VM’s settings. You might find it challenging to remember which VMs can be upgraded on the fly. Some administrators use scripts (PowerCLI) to list VMs with hot-add enabled for tracking. If you only enable it when needed, it’s easier to manage.

That said, there are absolutely valid use cases to enable it. Test/Dev environments often benefit from hot-add: you can crank up resources temporarily to run a heavy job and then not worry that you overspec’d the VM initially. Dynamic workloads or VNFs (Virtual Network Functions) that might scale with demand could use hot-add as a way to grow in place (though VMware has other solutions for elasticity too). If you’re using an automation/orchestration tool that knows how to trigger hot-add based on metrics (for example, vRealize Operations can suggest adding CPU to a VM when it’s peaking), then having it enabled could allow truly seamless scaling.

In summary, from a performance and operations standpoint: enable CPU or Memory Hot-Add on a VM only if you anticipate needing it. If you do enable it, monitor that VM’s performance and behavior, and know that you might be trading off a bit of efficiency for the convenience. For critical VMs where maximum performance is paramount and their resource needs are fairly static/predictable, you’re often better off sizing them appropriately and leaving hot-add off.

Conclusion

VMware’s CPU Hot-Plug and Memory Hot-Add are powerful features that underscore the flexibility of virtualization. They allow IT admins and cloud providers to respond to changing resource needs in real time – add a CPU to a web server during a traffic surge, or add RAM to a database VM when queries spike – all without shutting down the workloads. This capability can greatly reduce downtime and improve the agility of your environment.

In this article, we reviewed the requirements to use hot-add (such as hardware version and licensing), and we examined how various guest OSes behave when you give them extra CPUs or memory on the fly. As we saw, Windows Server 2019/2022 handle it effortlessly, enterprise Linux distros like RHEL and SLES also apply changes immediately, while Ubuntu/Debian require a nudge (or reboot) to make use of added resources, and FreeBSD doesn’t support it at all yet. Always check that your guest OS is on VMware’s supported list for hot-add, and test in a lab if possible – the actual behavior might vary slightly depending on kernel versions and configurations.

We also discussed why hot-add isn’t simply turned on everywhere: there are performance nuances (vNUMA, small overheads) and administrative considerations (no hot-remove, need to plan capacity, etc.). The table below summarizes which guest operating systems allow you to add vCPUs and memory without a reboot, and where limitations exist:

In closing, live VM hardware reconfiguration is a fantastic tool in the virtualization toolbox – it provides a safety net for those “oops, I sized it too small” moments and enables more uptime for critical services. But it should be used with understanding of its constraints. For production environments, weigh the convenience of hot-add against the potential need for consistent performance. Often, you might choose to scale out (add another VM) or schedule a quick maintenance reboot to add resources, rather than leaving hot-add enabled all the time. However, for many scenarios, the ability to respond in real time to workload demands is well worth any minor trade-offs. By knowing your OS support matrix and following best practices, you can confidently take advantage of CPU Hot-Plug and Memory Hot-Add in VMware vSphere to make your infrastructure more flexible and resilient.