OpenVZ or KVM: Which VPS Virtualization You Actually Want

An OpenVZ container shares the kernel of the machine it runs on. A KVM virtual machine boots its own. Every other difference you will find on a comparison chart, including the memory behavior and the list of software that will refuse to install, is downstream of that one fact.

The question that settles it is whether anything you plan to run needs to talk to the kernel on its own terms. Traffic has almost nothing to do with it. If the answer is no, OpenVZ gives you more machine for the money and you should take it. If the answer is yes, or if you cannot say for certain, KVM is the only one of the two that will not eventually stop you.

One Kernel or Two

KVM is full hardware virtualization. The host presents virtual CPUs, a virtual block device, and a virtual network card, and your guest boots a complete operating system on top of them, kernel and all. As far as your software can tell it is a physical server with slightly unusual hardware. You can install a different distribution, or an operating system that is not Linux at all. The kernel version is yours to pick.

OpenVZ is container virtualization, sometimes called operating system level virtualization. There is one kernel on the physical machine, and every container on it uses that kernel through namespaces and control groups. Your container has its own root filesystem, its own processes, its own network configuration, and its own root account. It does not have its own kernel, and it never will.

That is the whole difference. The rest of this post is consequences.

One quick way to see it: run uname -r inside a container and inside a KVM guest on the same host. The container reports the host's kernel version, which is often several major versions away from what your distribution normally ships. The KVM guest reports whatever it booted.

If You Share a Kernel, Here Is What You Give Up

Anything that loads a kernel module. modprobe inside a container either fails outright or silently does nothing, because loading a module means loading it into the host's kernel, and the host is not going to let one customer do that on behalf of everyone else on the box.

In practice, here is what that costs you:

• WireGuard, unless you fall back to the userspace wireguard-go implementation, which works but gives up the in-kernel performance that made WireGuard interesting. The official installation page treats the kernel module as the normal path.
• Anything needing /dev/net/tun. OpenVPN, Tailscale, and most other tunnel software want that device node, and on a container it exists only if the host operator enabled it for you. Many will, on request. Ask before you buy rather than after.
• Docker and anything built on it. Containers inside a container is a configuration that ranges from unsupported to fragile depending on the host's kernel and storage driver, and Docker's own installation requirements assume a normal kernel you control.
• Filesystem features that are not already compiled into the host kernel. ZFS is out. So is FUSE, which quietly takes sshfs and a good number of backup tools with it.

Custom sysctl values are the other common surprise. Plenty of the tunables you would reach for while fixing a connection-heavy workload, things under net.ipv4 and net.core, are read-only inside a container because they are global to the host. You can raise them on KVM. You cannot on OpenVZ, and no amount of root will change that. Root access is real either way, but on a container it stops at the kernel boundary.

None of this matters if you are running a website. A LAMP stack, a WordPress install, a Node application behind nginx, a small Postgres database: none of them touch the kernel in a way a container blocks.

Memory: Burst Is Not the Same as Guaranteed

Container hosts can advertise memory in two numbers. There is the amount your container is guaranteed, and there is a higher ceiling it may reach when the physical machine happens to have spare capacity. Read any plan comparison carefully enough and you will find the second number doing most of the marketing.

Burst memory is borrowed. When the host is busy, it is not there, and the allocation your process asked for fails at exactly the moment your site is under load, which is the same moment every other container on that host is also reaching for its burst allowance.

KVM does not work that way. The guest is handed its memory at boot and the guest kernel manages it. Ballooning exists, and some providers use it, but the baseline behavior is that the RAM is assigned to your machine and stays assigned.

There is a real cost on the KVM side, and burying it would be dishonest: a slice of the memory you paid for goes to running your own kernel and its page cache. A container borrows all of that from the host for free. On small allocations that overhead is a meaningful fraction of the total, which is the strongest honest argument for containers at the low end.

Reporting differs too, and it breaks things quietly. free -m inside some container setups reflects host state rather than your own limit. Software that sizes itself from available memory then guesses wrong. MySQL tuning scripts read it. So do the JVM heap defaults and every PHP-FPM process calculator anyone has ever pasted into a config file. Check /proc/user_beancounters if it exists on your container, because that is the file that tells you what your actual limits are and how many times you have already hit them. A non-zero failcnt is the clearest signal you will get that the plan is too small before the symptoms of an undersized plan start showing up in your logs.

Swap deserves a sentence. Containers get an emulated swap allowance rather than a real swap device, so the usual assumption that a machine under memory pressure will slow down before it kills anything does not hold. It kills the process.

Why OpenVZ Costs Less for the Same Advertised Numbers

Density. One kernel serves every container on the machine, so there is no per-guest operating system overhead and no per-guest page cache. A physical server fits considerably more containers than virtual machines, and because containers only consume memory they are actually using, the host can allocate more than it physically has and rely on the fact that most customers idle most of the time.

That is not a trick, and it is not dishonest. It is a genuine efficiency, and it is the reason a container plan can show a larger number next to RAM and disk for less money than a KVM plan showing a smaller one. You are buying a share of a pool rather than a reservation.

The trade is variance. On a quiet host you get more than you paid for. On a busy one you get what you were guaranteed and no more, and your neighbors' behavior becomes your performance problem. If your site earns money and an hour of degraded response time costs you something you can name, buy the reservation.

Do You Actually Need KVM?

Ask one question about the software you intend to run: does it need to load a kernel module, boot its own kernel, or write a global kernel tunable?

Work through what you are actually deploying.

1. A website, a CMS, a database, a nightly cron job. No. A container runs all of it.
2. A VPN endpoint, a mail server with strict filtering rules, a firewall doing anything beyond basic packet filtering. Usually yes, because these are the workloads that reach for modules.
3. Docker, Kubernetes, or any container orchestration of your own. Yes.
4. A non-Linux operating system, a specific kernel version, or full disk encryption on the guest. Only KVM can do it.

Notice that visitor numbers appear nowhere in that list. A container with adequate CPU and memory serves a heavily trafficked WordPress site perfectly well, and a KVM guest with the same resources will not serve it noticeably better. The line is capability, not scale.

The second question, and people skip it: who administers the box? Neither technology makes an unmanaged server easier to run, and the choice between a managed and a self-managed VPS affects your day far more than the choice between OpenVZ and KVM. If you are picking KVM specifically to install something exotic, you are also signing up to maintain it.

OpenVZ vs KVM, Side by Side

Which One to Order

Two recommendations.

Buy an OpenVZ VPS when you know the full list of what will run on the machine and none of it is on the exclusion list above. Web applications and the databases behind them fit that description, which covers most of the reasons anyone buys a VPS in the first place. You will get more resources for the money, and the capabilities you gave up were ones you were never going to use.

Buy a KVM VPS when you cannot finish that sentence with confidence. The premium you pay is small next to the cost of discovering nine months in that the one tool your project now depends on will not install, because at that point your options are a migration or a workaround you will maintain forever. Uncertainty is a real requirement and it deserves to be priced like one.

Before you order either, write down every piece of software the server will run, including the monitoring agent and the backup client, and check each one against the kernel question. Ten minutes with that list settles the choice more reliably than any comparison chart, this one included. If you are still working out whether a VPS is the right tier at all, the VPS hosting definition page covers that ground, and the VPS plans show both virtualization types side by side.