Performing a VM Hot Add of CPU and Memory in vSphere
A VM hot add increases the CPU or memory allocated to a powered-on virtual machine without shutting down the guest. In vSphere, processor additions are usually called vCPU hot add, while memory additions are described as memory hot plug. The guest receives new virtual hardware while its applications keep running, provided the virtual machine options, firmware, operating system and workload all support online reconfiguration.
Australian teams in Sydney, Melbourne and Brisbane often run on-premises vSphere estates alongside Azure or AWS, so hot add remains useful for seasonal demand, VDI bursts and migration work. Local teams generally spell the discipline virtualisation and may say it is worth a proper look before a risky change. Where change management follows the ASD Essential Eight, keep the update documented, reversible and tested outside business hours.
Check support before changing the VM
Start in vSphere Client by checking the VM’s hardware version, guest OS, firmware and virtual hardware options. CPU Hot Add and Memory Hot Plug must be available under the VM options, and the guest must support the relevant change. A VM already powered on cannot usually enable a missing option without a planned power cycle, so verify this before promising an uninterrupted upgrade.
Keep VMware Tools current and review the guest OS release notes for processor and memory hotplug support. Tools improve device visibility and status reporting, but they do not enable unsupported host-side hot add. Also check whether the application is sensitive to processor topology; a live vCPU increase can expose NUMA or scheduler issues even when the operating system accepts it.
Record the current vCPU count, memory, CPU Ready, swap rate and power state, then confirm a configuration backup and a tested recovery path. The site disclaimer also makes clear that version-specific behaviour and commercial support terms should be checked against your own environment.
Choose the right CPU and memory increase
Size the CPU increase from measured demand rather than a round number. Review CPU Ready and ready-to-run time in vCenter, then increase the virtual processor count in steps that match the existing socket and core topology where your design guide permits. The new count is a total, not an increment; an application tied to a cgroup, CPU limit or licence may also need separate adjustment.
For memory, calculate the active working set, cache and swap rather than copying the physical host’s free RAM. Confirm that the guest OS can online new memory and that virtual NUMA settings will not work against the requested layout. Memory hot plug adds capacity, but it does not remove ballooning pressure or an application memory cap.
Check host contention at the same time. CPU overcommit and datastore latency can make a larger VM feel no faster, while slow storage can still bottleneck an otherwise successful hot add. Optimising vSphere storage is useful for separating I/O limits from compute and memory constraints before production sizing is locked in.
Apply the hot add in vSphere
In vSphere Client, open the powered-on VM, choose Actions or Summary, then open Edit Virtual Hardware Settings. Increase CPU under the processor section and Memory under the memory section. Apply the edit and watch the recent tasks panel; vSphere itself does not require a guest reboot for a supported online increase.
Keep the first test modest and change only the resource under investigation when practical. A sudden large increase can alter scheduler placement, NUMA affinity or application cache assumptions. Confirm that the VM remains powered on, the task completes without an automatic reboot and vCenter shows the intended final counts.
PowerCLI can perform the same update. The counts below are final totals, and -NoShutdown requires an online reconfiguration rather than an implicit power-off:
$vm = Get-VM -Name 'app01'
Set-VMProcessor -VM $vm -Count 8 -NoShutdown
Set-VMMemory -VM $vm -SizeGB 24 -NoShutdown
Confirm both hot-add options first; if the platform rejects the request, correct the prerequisite rather than forcing a shutdown.
Confirm the guest sees the new resources
Inside the guest, verify the change before declaring success. On Windows, check Task Manager, System Information and the System event log. On Linux, compare lscpu and free -h with the pre-change values, inspect the kernel log and review the online memory nodes. An unchanged guest view points to OS support, drivers or a failed virtual hardware task.
Next, test the service rather than only the operating system. Exercise logins, application jobs and memory-heavy workflows, then watch CPU Ready, swap, ballooning and latency. New vCPUs are not automatically used equally by every process, and some software needs its own restart or topology awareness. Downsizing is a different operation: removing CPU or memory normally needs a shutdown.
Resolve common hot-add failures
If the hot-add controls are absent, the VM may need CPU Hot Add and Memory Hot Plug enabled while powered off. Confirm that the hardware version, guest firmware and vSphere release support the intended path. Upgrading virtual hardware can expose newer settings, but it may also change devices or boot behaviour, so treat it as a separate controlled change.
If the guest accepts the change but shows the old resources, check VMware Tools, guest drivers and memory hotplug support in that OS. For processor issues, review socket and core placement and NUMA rather than adding more vCPUs blindly. For memory, check whether the OS failed to online the new pages or whether the application remains limited by its own configuration.
For PowerCLI failures, capture the full error, run under an account with appropriate permissions and inspect vCenter tasks and audit logs. A generic command failure often means the hot-add option, hardware version or guest capability is missing. The wider VMware series provides related vSphere administration material for tracing configuration problems without treating every symptom as a capacity issue.
Choose one non-production VM, verify its current configuration and perform a small CPU increase followed by a memory hot plug while watching vCenter and the guest. Record timings, task output and application impact, then repeat the runbook during a normal change window. That gives your team a tested, repeatable hot-add procedure before production demand rises.