How to Allocate CPU and RAM to Proxmox VMs and LXC Containers

On a Proxmox VE host, virtual machines (VMs) and Linux containers (LXC) share the host’s physical processors and memory. CPU and RAM settings control how much each VM or container can use, but they do not all reserve that capacity on the host. CPU overcommit lets guests share processor time even when their combined virtual CPU assignments exceed the host’s physical cores. RAM overcommit sets guest memory limits whose combined peaks exceed the memory available to guests, creating a risk of swapping or out-of-memory failures if demand rises together.

Set CPU capacity and limits for each VM or container based on its workload, then check whether guests compete for host processor time before adjusting those settings. For RAM, reserve capacity for Proxmox and storage first, and treat ballooning and container limits as controls rather than guarantees. Proxmox schedules CPU time across guests, while guests under simultaneous memory pressure still need physical RAM.

Set CPU capacity separately from CPU limits

A VM’s virtual CPUs, or vCPUs, are the processors the guest operating system sees. Proxmox schedules their work onto the host’s physical CPUs; assigning four vCPUs does not reserve four physical cores. A VM’s cpulimit sets a ceiling on its total host CPU time. Proxmox expresses that limit in CPU-time equivalents: 1.0 represents 100% of one CPU’s time, while 2.5 represents 250%. A four-vCPU VM running all four vCPUs at full capacity could use 400%.

For an LXC container, cores controls how many CPUs the container can see, while cpulimit caps its total CPU use. For example, a container configured with two visible cores and cpulimit set to 0.5 is capped at half a CPU’s time. The cpuunits setting gives a container a relative scheduling weight against other running containers. A higher weight gives it a larger share when containers compete for CPU time; it does not reserve processor time or set a hard cap. Proxmox documents a default weight of 100, or 1024 on hosts using legacy cgroup v1. These controls are described in the VM CPU documentation and container CPU documentation.

CPU overcommit suits workloads whose peaks do not happen at the same time. When several guests need full CPU capacity at once, they compete for host processor time, so latency-sensitive or sustained workloads need more headroom. Proxmox does not specify a universally safe ratio of assigned vCPUs to physical cores. Start conservatively for demanding workloads, then check host CPU contention and guest performance under representative peak load.

Use VM ballooning as a managed range

The configured memory value sets the most RAM a VM can use. Setting the minimum memory to the same amount gives the VM a fixed allocation. Proxmox can still present a ballooning device in this configuration, which provides guest-memory information; its presence alone does not mean the VM is dynamically receiving or returning RAM.

Ballooning lets Proxmox adjust a VM’s memory between a configured minimum and maximum with help from a balloon driver inside the VM. The driver exchanges memory with the host. For VMs configured with a lower minimum than maximum, Proxmox VE 9.2 describes keeping the minimum available and adding memory up to the maximum when host use is below a target. Its default ballooning target is 80%, configurable per node with pvenode config set --ballooning-target. That target guides automatic allocation; it does not guarantee that every VM can reclaim needed memory or that the host will avoid memory pressure. See the Proxmox VE 9.2 Administration Guide and confirm behavior in the documentation for the installed release.

The balloon driver’s availability depends on the guest operating system. Proxmox says Linux distributions released after 2010 include the driver. For Windows, the guide says to add the driver manually and warns that it may slow the guest, advising against it for critical systems. If the host runs short of RAM, VMs may return memory; the host may also swap, and the out-of-memory (OOM) killer can act as a last resort. Ballooning therefore helps manage memory sharing, but it does not make an overcommitted host safe from exhaustion.

When several VMs use automatic allocation, memory shares affect how Proxmox distributes additional available memory relative to their minimums. For example, a VM with 3,000 shares receives three times the relative weight of one with 1,000 shares when Proxmox distributes that pool. Shares do not change a VM’s configured minimum or maximum.

Set LXC memory ceilings and swap deliberately

Proxmox controls LXC memory through Linux’s cgroup resource controls, which limit a group of processes. The container’s memory setting sets its memory ceiling. Its swap setting controls additional use of host swap; the documented cgroup total is the sum of memory and swap. These settings limit use without reserving an equal amount of physical RAM for the container.

Administrators can set container memory ceilings whose combined total exceeds the host’s usable memory. If several containers approach their limits at once, the host faces memory pressure. Set each limit according to the container’s workload, and account for the combined peak demand rather than assuming every container will stay below its ceiling. Proxmox’s container documentation describes memory and swap limits; it does not describe an LXC equivalent to VM ballooning.

Reserve host memory before sizing guests

Proxmox’s hardware requirements call for at least 2 GB for the operating system and Proxmox VE services, in addition to guest memory. The requirements also estimate about 1 GB of additional memory per terabyte of used storage for Ceph or ZFS. These figures are planning guidance, not a complete reserve for every workload. The Proxmox hardware requirements provide the stated figures; monitor actual host use and allow for workload peaks.

A practical allocation starts by reserving memory for Proxmox services and storage, then sizes guest memory against expected peak demand. For VMs, set a minimum the workload can tolerate and a maximum that fits the intended peak scenario. Set container memory and swap ceilings to contain individual workloads, without assuming every container will stay below those limits. For CPU, use vCPU counts to provide useful parallel capacity and apply limits only when you need to constrain a guest’s total CPU consumption.

After setting these values, observe host memory pressure and swap use during representative peak workloads. Check CPU contention and guest performance under those same workloads. If guests slow down or the host swaps under load, reduce the combined demand or add capacity. Proxmox documents the controls, but it does not prescribe a universal CPU or RAM overcommit ratio.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com