“VPS” describes the product, not the technology underneath. Two very different approaches are sold under the same name: full virtualization (KVM, also Xen, VMware, Hyper-V) and container-based virtualization (OpenVZ, LXC/LXD). The difference determines what you can install, how isolated you are and how predictable performance is.

The short version

  • KVM: each VPS is a complete virtual machine with its own kernel. Behaves like a dedicated server. Runs any Linux distribution, Windows, Docker, WireGuard, custom kernels.
  • OpenVZ / LXC: each VPS is a container sharing the host’s kernel. Lighter for the provider, but you can’t change the kernel or load modules, and some software doesn’t work.

How they work

KVM (Kernel-based Virtual Machine) is built into the Linux kernel. It uses CPU virtualization extensions (Intel VT-x, AMD-V) to run guest operating systems directly on the processor, isolated by the hardware. Each guest has virtual hardware — CPUs, memory, disks (usually VirtIO), network cards — and boots its own kernel.

Containers isolate processes using kernel features (namespaces, cgroups). All containers on a host run on one shared kernel. There’s no boot process for a guest kernel and very little overhead.

Comparison

KVM OpenVZ 7 LXC/LXD
Own kernel Yes No (host kernel) No (host kernel)
Change kernel / load modules Yes No No
Windows Yes No No
Docker Yes Limited/often no Possible with nesting, configuration-dependent
WireGuard (kernel module) Yes Only if host provides it Only if host provides it
Custom firewall (nftables/iptables) Full Restricted Mostly
Swap Real swap Often “fake” vSwap Host-dependent
Isolation Strong (hardware virtualization) Weaker (shared kernel) Weaker (shared kernel)
Resource guarantees RAM allocated to the VM Easier to oversell Easier to oversell
Overhead Small (modern CPUs) Minimal Minimal

Why it matters in practice

Software compatibility. Docker, Kubernetes (k3s), WireGuard, some VPN software, ZFS, custom kernels (e.g. for BBR on old distros), and anything that loads kernel modules generally need KVM. On a container VPS you depend on whatever the host kernel provides.

OS choice. On KVM you can run any distribution — and Windows Server. On containers, you can only run Linux distributions compatible with the host’s kernel version; very new distributions may not work on old hosts.

Security isolation. A kernel vulnerability on a container host can, in the worst case, affect all containers. Hardware-virtualized guests have an extra layer between them.

Performance consistency. Container platforms make it easy to sell more resources than physically exist (“overselling”), because unused memory in one container is available to others. KVM allocates memory to each VM, so what you buy is much closer to what you get. (CPU time is shared on both — watch for steal time.)

Memory reporting. Inside containers, tools like free sometimes show confusing numbers (“burst” memory, fake swap). On KVM, free -h shows your VM’s real memory.

Where containers make sense

Containers are excellent technology — that’s why Docker is so popular. As a VPS product, they make sense for very cheap, small instances running simple workloads (a static site, a small bot) where kernel features don’t matter. Running your own containers (Docker, LXC) inside a KVM VPS gives you the best of both.

How to check what you have

systemd-detect-virt
  • kvm → KVM virtual machine
  • openvz → OpenVZ container
  • lxc → LXC container

Other hints: hostnamectl shows “Virtualization: kvm”; ls /proc/vz exists on OpenVZ; on containers uname -r shows the host’s kernel, which you can’t change.

Our choice

Every VPS.DO plan runs on KVM: full root access, your own kernel, Linux or Windows Server (on plans with at least 50 GB disk), Docker and VPNs without restrictions. See KVM VPS hosting, and for more background read what is a VPS and VPS vs VDS.

  • KVM
  • Virtualization
  • VPS