KSM in Proxmox:
sharing RAM across VMs

The kernel deduplicates memory

KVM virtualisation marks VM memory as "mergeable" (madvise(MADV_MERGEABLE)). The kernel thread ksmd scans those regions in the background, checksums 4 KB pages and, when it finds identical pages owned by different VMs, keeps a single physical copy and points the other mappings at it in copy-on-write (COW) mode.

As long as no VM modifies such a page, they all share one copy in RAM. The moment one writes to it, the kernel instantly makes a private copy for that VM. From the guest's perspective nothing changes; the saving happens entirely on the host side.

Homogeneous environments gain the most

KSM works better the more machines hold the same data in memory: the same OS, the same libraries, the same binaries. The classic case is dozens of VMs from one base image (e.g. 40× Debian or a farm of identical Windows Servers) — shared guest-kernel pages, glibc/.NET libraries and zeroed pages merge en masse.

• Big gain: many VMs with the same OS and a similar app stack (VDI, hosting, application farms).
• Medium gain: mixed Linux of the same family — many libraries are shared anyway.
• Small gain: a few very different, large VMs (different OSes, databases on hugepages) — few pages repeat.

In practice, on homogeneous clusters KSM recovers a realistic tens of percent of RAM — i.e. fitting more VMs on the same hardware without buying memory.

Enabled automatically — under control

Proxmox runs the ksmtuned service, which enables KSM only under memory pressure — by default once host RAM usage crosses a threshold (around 80% of physical memory). So on a lightly loaded host KSM doesn't waste CPU scanning, and kicks in exactly when it helps.

The saved RAM is approximately (pages_sharing − pages_shared) × 4 KB. On a healthy, homogeneous host this can be gigabytes.

What to be aware of

• CPU cost: scanning memory consumes CPU cycles. Under heavy RAM pressure it's a worthwhile trade-off, but on latency-critical hosts it's worth measuring.
• NUMA: by default KSM may merge pages across NUMA nodes, which can hurt memory latency. On large servers consider merge_across_nodes=0.
• Security (multi-tenant): deduplication is a known side-channel vector (access timing reveals that a page is shared). In multi-tenant, untrusted environments consider disabling KSM or limiting it to trusted VM groups.