KVM vs OpenVZ vs LXC Virtualization: What Actually Matters for Your VPS

oleh

When you buy a VPS, the plan-page specs (2 vCPU, 4 GB RAM, 80 GB SSD) only tell half the story. The other half is the virtualization underneath: KVM vs OpenVZ vs LXC decides whether you can load your own kernel modules, run Docker, rely on swap, and trust that your RAM is really yours. This guide covers the buyer side: what each technology means once you have root access and a project to ship.

The short version

  • KVM is a full virtual machine with its own Linux kernel. You pick the OS, load kernel modules, and run Docker without asking the host. RAM is hard-allocated to you.
  • OpenVZ is a container sharing the host’s kernel. Cheap and light, but you cannot change the kernel and memory limits are soft. The old versions are dead; only OpenVZ 7 is current.
  • LXC is the modern container system, also sharing the host kernel but built on current Linux features (cgroups, namespaces). You mostly meet it running your own node (Proxmox), not renting a VPS.

Rule of thumb: production workloads and Docker go on KVM. Cheap OpenVZ is fine for a sandbox or learning.

KVM: a computer inside a computer

KVM (Kernel-based Virtual Machine) is full virtualization. The hypervisor hands your guest virtual CPUs, a block of RAM, a virtual disk and a virtual network card, and your guest boots its own kernel on top of that. To your software, it looks like a real machine.

That one fact, owning your kernel, is where all the practical benefits come from:

  • Any OS. Ubuntu, Debian, Rocky, Alpine, FreeBSD, even Windows. The host does not care.
  • Kernel modules. Need WireGuard, a custom filesystem, or a specific driver? modprobe it yourself. No ticket to the provider.
  • Your own sysctl. Kernel tuning applies to you alone.
  • Docker just works. You control the kernel, so Docker, Kubernetes and any container runtime install normally.
  • Real swap. Swap inside the guest is a real partition or file on your virtual disk. If your app briefly needs more memory than RAM, it pages to disk instead of getting killed.

KVM has overhead: each guest runs a full OS, so a node fits fewer VMs than containers. That is part of why KVM plans cost a little more. You pay for isolation enforced by hardware, not by policy.

OpenVZ: cheap containers, and the version problem

OpenVZ is OS-level virtualization. Instead of a virtual machine, you get a container: your own filesystem, processes and network view, but you run on the host’s kernel. There is no guest kernel at all.

That makes OpenVZ fast to provision and cheap to sell, which is why budget VPS plans loved it. The limits that bite buyers:

  • No kernel control. You cannot load modules or change the kernel version. If the host runs an old kernel, your “Ubuntu 24.04” container still runs that old kernel, and newer features like recent WireGuard or eBPF tooling may be unavailable.
  • Docker is a fight. It needs specific host-side configuration. Some providers enable it, many do not, and even when it works you are stacking containers on containers with known quirks.
  • Swap is not really swap. OpenVZ historically used “vSwap” or burstable memory. On old versions free -h can even show the host node’s total RAM, which misleads monitoring tools.
  • Overselling is easy. Memory limits are soft, so a provider can sell more RAM than the node has. When every container gets busy at once, everyone slows down and the OOM killer starts picking victims.

OpenVZ 7 vs the legacy versions: this matters

Not all “OpenVZ” is the same thing: the classic lineage (6 and earlier, old RHEL kernels) is unmaintained, with no kernel security fixes.

OpenVZ 7, maintained under the Virtuozzo umbrella, is the current line: newer kernels, better tooling, and it can even run KVM virtual machines alongside containers on the same host. If a provider sells “OpenVZ” without naming the version, ask which one the node runs. A provider that cannot answer is a red flag.

LXC: the container you run yourself

LXC (Linux Containers) is the modern way to do what OpenVZ did: lightweight containers using kernel features (cgroups for resource limits, namespaces for isolation) that are part of mainline Linux. No patched kernel required.

You rarely buy an “LXC VPS” from a hosting company. You meet LXC when you run your own infrastructure: Proxmox VE uses LXC for containers alongside KVM for virtual machines, and homelab users run LXC for lightweight services on a single node.

Like OpenVZ, LXC shares the host kernel, so kernel modules and OS choice (Linux only) are limited the same way. Resource limits are enforced by cgroups, cleaner and more predictable than the old OpenVZ beancounter system. Docker inside LXC needs nesting, which weakens isolation; for Docker on your own node, a KVM guest is the safer home.

KVM vs OpenVZ vs LXC: side-by-side

Feature KVM OpenVZ LXC
Type Full virtualization (own kernel) Container (shared kernel) Container (shared kernel)
OS choice Any: Linux, BSD, Windows Linux only Linux only
Custom kernel modules Yes No No
Docker support Full, no special setup Needs host config, often broken Possible with nesting (weakens isolation)
Swap Real swap inside the guest vSwap / burstable, not real swap Depends on host config
Memory guarantee Hard-allocated Soft limits, easy to oversell cgroup-enforced
Isolation Hardware-level Shared kernel Shared kernel
Typical price Higher Cheapest Rarely sold as VPS
Status Industry standard Legacy versions dead; v7 current Active, modern

The four things that actually affect you

1. Who owns the kernel

This is the root of almost every difference. On KVM, uname -r shows your kernel and you can change it. On OpenVZ or LXC it shows the host’s kernel and you cannot change it. Before buying, decide whether your stack needs anything kernel-level: WireGuard modules, eBPF-based monitoring, or a kernel newer than what a budget host runs.

2. Swap that is not swap

On KVM, when RAM fills up, the guest swaps to disk and slows down gracefully. On old OpenVZ there is no real swap: the container hits its limit and processes get killed. If your app has occasional memory spikes (a PHP worker, a big composer install), KVM’s real swap is the difference between “slow for a minute” and “mysteriously dead at 3 AM”. On OpenVZ, check /proc/user_beancounters: nonzero values in the failcnt column mean your container already hit its limits.

3. Docker compatibility

Docker is the clearest practical test. On KVM it installs and runs like on bare metal. On OpenVZ it depends on the provider enabling nested container support, with storage-driver and networking quirks even then. On LXC it needs nesting, at the cost of weaker isolation. If your pipeline assumes Docker, KVM removes a whole category of “works on my machine” problems.

4. Overselling risk

Containers are cheap to oversell because limits are soft: nothing stops a host from promising 4 GB to ten containers on a 16 GB node. KVM makes this structurally harder because RAM is carved out per guest. On OpenVZ you feel overselling as sudden slowdowns and OOM kills when neighbors get busy. No command proves a provider is honest; consistent performance over weeks plus a provider that names its virtualization openly is the real signal.

How to check what your VPS is running

Not sure what is underneath your current VPS? Three commands tell you:

systemd-detect-virt
# returns "kvm" on KVM, "openvz" on OpenVZ, "lxc" on LXC

cat /proc/vz/veinfo 2>/dev/null && echo "OpenVZ detected"
# file only exists inside an OpenVZ container

uname -r
# compare against your distro's expected kernel; a mismatch hints at a container

On KVM, cat /proc/cpuinfo | grep "model name" shows the real CPU model; inside some containers it shows a generic value.

Which one should you pick?

  • Pick KVM for production websites, apps, Docker, game servers, VPNs needing kernel modules, Windows, or anything where stability beats saving a dollar.
  • Pick OpenVZ (version 7, from a provider that says so) for throwaway sandboxes, learning Linux, a cheap static site, or a personal VPN where you accept the limits. Avoid legacy OpenVZ entirely.
  • Pick LXC when you run your own node (Proxmox, homelab) and want lightweight Linux services with minimal overhead. Commercial LXC VPS plans are barely a product category, so do not go hunting for them.
  • When in doubt, pick KVM. The price gap between budget KVM and OpenVZ has shrunk; check official pricing and you will find KVM close to the container plan, which makes the isolation an easy trade.

Before you buy any VPS, ask which virtualization the plan uses and, if the answer is OpenVZ, which version. Providers that answer clearly tend to be the ones worth trusting.

FAQ

Is OpenVZ dead?

Classic OpenVZ (6 and earlier) is unmaintained; avoid it. OpenVZ 7 under Virtuozzo is the current line. Always confirm which version a provider runs.