How to Increase CPU and RAM Resources for a Virtual Machine in Proxmox VE

Introduction

You spin up a VM in Proxmox VE with the defaults - 2 cores, 2 GB of RAM - and it works fine for a while. Then you install something heavier, a Nextcloud instance, a Plex server transcoding video, a small Kubernetes node, and suddenly the VM is crawling. The obvious fix is to give it more CPU and more memory, but if you've never done it before, the settings panel has enough options to make you hesitate before clicking anything.

The good news: resizing a VM's CPU and RAM in Proxmox VE is one of the simpler admin tasks once you understand what each field actually controls. This walks through doing it safely from both the web GUI and the command line, on Proxmox VE 8.x and 9.x, plus the handful of ways it can go sideways if you're not paying attention.

What You Will Learn

• What "sockets," "cores," and "memory" actually mean in a VM's hardware config
• How to change CPU and RAM allocation from the GUI
• How to do the same thing with qm set from the shell
• The difference between a resize that needs a reboot and one that doesn't (CPU/memory hotplug)
• Why your guest OS sometimes doesn't "see" the new resources right away
• Common errors and how to fix them
• How much headroom to leave on the host so you don't starve it

What Is This Feature?

Every VM in Proxmox is really just a QEMU process running on the host, and CPU/RAM allocation is just telling QEMU how big to make that process look to the guest. On the CPU side, Proxmox exposes two separate numbers: Sockets and Cores. Sockets is how many physical CPU packages the guest thinks it has, and cores is how many cores live on each one. Multiply them together and that's the total vCPU count the guest OS sees. For almost every homelab or small business VM, you want Sockets left at 1 and just bump Cores up - splitting across multiple virtual sockets only matters for licensing quirks in certain enterprise guest OSes.

Memory is more straightforward: it's the amount of RAM, in MiB, that the guest is allowed to use. There's also an optional Ballooning feature that lets Proxmox reclaim unused memory from a guest and hand it back to the host, but that's a deeper topic on its own - for this guide, just know that if "Ballooning Device" is checked and you set a lower "Minimum memory," the guest's usable RAM can shrink under host memory pressure. If that surprises you, turning ballooning off and setting a fixed amount is the simpler, more predictable option.

Why Would You Use It?

Most of the time you're doing this reactively - a VM feels sluggish, and top or htop inside the guest shows the CPU pegged at 100%, or free -h shows almost no memory free and the OOM killer is starting to end processes. Bumping cores or RAM is the direct fix.

Sometimes it's proactive instead. You built a test VM with minimal resources to save space during setup, and now that it's doing real work, it deserves a real allocation. Or you're consolidating - retiring an old physical server and want its replacement VM to actually match what the hardware used to provide.

Either way, this is one of the lowest-risk changes you can make to a VM. Unlike storage changes, which can be destructive if done wrong, adjusting CPU and memory is fully reversible and doesn't touch your disk data at all.

Prerequisites

• A running Proxmox VE host, 8.x or 9.x (the steps below are identical on both)
• An existing VM you want to resize
• Root access, or a user account with the VM.Config.HWType and VM.Config.Memory permissions on that VM
• Enough free CPU cores and RAM on the host to actually cover the increase - check Datacenter > your node > Summary before you start
• The QEMU Guest Agent installed in the VM if you want hotplug changes to apply without a reboot

Step-by-Step Tutorial

Checking what the host can actually spare

Before touching the VM, look at the node's summary page in the Proxmox web UI. It shows total CPU usage and total memory usage across everything running on that node. If the host already has 90% of its RAM committed to other VMs, adding another 8 GB to this one is going to cause trouble for everyone, not just this guest.

A rough rule that works well in practice: leave at least 10-15% of host RAM free, more if you're running ZFS (its ARC cache wants headroom too), and don't allocate more total vCPUs across all VMs than roughly 2-4x your physical core count unless you know your workloads are mostly idle.

Changing resources from the GUI

1. In the Proxmox web interface, click the VM in the left-hand tree.
2. Go to the Hardware tab.
3. Click Processors, then Edit. Change the Cores value to whatever you need - leave Sockets at 1 unless you have a specific reason not to.
4. Click Memory, then Edit. Set the new amount in MiB (1024 MiB = 1 GiB, so 8192 for 8 GB).
5. Click OK on each dialog.

If the VM is running and hotplug isn't enabled, you'll see the new values listed but the VM's actual running resources won't change until you shut it down and start it again - a reboot from inside the guest OS isn't enough, because that doesn't restart the underlying QEMU process. Use Shutdown, wait for it to power off, then Start.

Changing resources from the shell

SSH into the Proxmox host (or use the built-in Shell button in the web UI for that node), then find the VM's ID with:

qm list

Set the core count:

qm set 101 --cores 4

Set the memory (in MiB):

qm set 101 --memory 8192

Replace 101 with your VM's actual ID. Both commands take effect the moment you run them in the config file, but as with the GUI, a running VM without hotplug enabled needs a full stop/start cycle before the guest actually sees the change.

Enabling hotplug so you don't need to reboot

If downtime is something you want to avoid, Proxmox supports CPU and memory hotplug - adding resources to a running VM without restarting it. It has a few moving parts, and it's worth understanding before you rely on it for anything important.

1. Shut the VM down once (hotplug settings themselves require a restart to take effect - this is the one exception).
2. In Options, edit Hotplug and check both CPU and Memory (along with the defaults, disk and network).
3. For CPU hotplug to actually let you add cores later, set Cores to the maximum you might ever want, then use vCPUs under the Processors edit dialog to set how many are active right now. Raising the vCPUs value later is what triggers the hotplug.
4. Start the VM.

Inside a modern Linux guest (Ubuntu 22.04+, Debian 12, etc.) new vCPUs show up automatically - check with nproc or lscpu. Memory usually needs one extra nudge: newly added memory blocks often land in an "offline" state until udev brings them online, and if that doesn't happen automatically you can force it with a for loop over /sys/devices/system/memory/memory*/state, echoing online into any block still marked offline. Windows guests need a trip to Device Manager and a "Scan for hardware changes," and CPU hotplug on Windows is far less reliable than on Linux - honestly, I'd just plan for a quick reboot on Windows VMs rather than fighting with hotplug.

Commands Explained

Common Errors

"parameter verification failed: cores: value should be in range [1, 128]" - you tried to set more cores than Proxmox allows in a single socket, or entered something like 0 or a non-numeric value. Stay within the range and remember it's cores per socket, not total.

The VM won't start after a memory increase, with a "start failed: command ... failed: got timeout" or a memory allocation error in the task log - almost always means the host doesn't actually have that much free RAM once you account for other running VMs, ZFS ARC, and the host OS itself. Check Datacenter > Node > Summary for actual free memory before assuming it's a config problem.

New vCPUs or memory don't appear inside the guest after a hotplug change - the QEMU Guest Agent isn't installed, or hotplug wasn't enabled in the VM's Options before you tried to add resources. Both need to be in place ahead of time; you can't retroactively hotplug into a VM that was started without hotplug turned on.

Windows Task Manager shows the old CPU/RAM count even though Proxmox reports the new values - Windows caches hardware info more aggressively than Linux. A restart of the guest (not the whole VM, just an in-guest reboot) usually clears it up if hotplug isn't fully working.

Troubleshooting

Start by confirming what Proxmox thinks the VM's config actually is, from the shell:

qm config 101

Compare that against what the guest OS reports. On Linux, nproc and free -h. On Windows, Task Manager's Performance tab. If Proxmox's config and the guest's view disagree, the VM almost certainly needs a full restart rather than relying on hotplug.

If the VM refuses to boot at all after a change, check the task log for the start action - it'll usually spell out exactly why, whether that's a memory shortfall or an invalid core count. If you're not sure what changed, qm config before and after is the fastest way to spot it, since it's easy to fat-finger a units mistake (typing 8 when you meant 8192 MiB, for instance, which quietly gives the VM 8 MB of RAM instead of 8 GB).

One thing that trips people up on ZFS-based hosts specifically: memory that looks "free" in free -h on the host is often held by the ZFS ARC cache and gets released under pressure, but Proxmox's own memory accounting in the GUI doesn't always make that obvious. If a VM fails to start with a memory error even though the summary page shows free RAM, check arc_summary or arcstat before assuming something's broken.

Best Practices

• Leave Sockets at 1 and adjust Cores instead, unless a specific guest OS license requires otherwise.
• Don't allocate 100% of host RAM to VMs - leave real headroom for the host, especially with ZFS.
• Install the QEMU Guest Agent from the start on any VM you might want to resize later without downtime.
• Prefer a clean shutdown/start over hotplug for anything you can schedule a maintenance window for - it's more predictable and there's nothing to troubleshoot afterward.
• Check qm config after any change to confirm it actually took, rather than trusting the GUI form alone.

Frequently Asked Questions

Do I need to restart the VM after changing CPU or RAM?

Yes, unless hotplug was already enabled in the VM's Options before you made the change. Otherwise the new values are saved to the config but won't apply until you shut down and start the VM again.

What's the difference between Sockets and Cores?

Sockets is how many virtual CPU packages the guest sees; Cores is how many cores per package. Total vCPUs is Sockets times Cores. For most VMs, set Sockets to 1 and adjust Cores alone.

Can I over-allocate more vCPUs than my host actually has?

Yes, Proxmox allows it, and it's common practice since most VMs don't use their full CPU allotment at once. Just don't push it too far on hosts running CPU-intensive workloads, or every VM will slow down under contention.

Why does my VM show less free memory inside the guest than I assigned?

Check whether Ballooning is enabled with a lower minimum memory value - under host memory pressure, Proxmox can reclaim RAM from the guest down to that minimum. Disable ballooning or raise the minimum if you want a fixed, guaranteed amount.

Does resizing CPU or RAM affect my VM's disk data?

No. CPU and memory changes only touch the VM's hardware configuration file, not its virtual disks. There's no risk to your data from this operation.

Conclusion

Resizing a VM's CPU and RAM in Proxmox comes down to two numbers and one decision: whether you're okay with a quick restart or want to set up hotplug ahead of time. Most homelab setups don't need hotplug at all - a scheduled restart takes seconds and avoids the handful of guest-side quirks that come with adding resources on the fly. Whichever way you go, keep an eye on what the host actually has to spare, and qm config will always tell you the truth about what's currently applied.