KVM vs OpenVZ vs LXC — Why the Virtualisation Type Matters

Own kernel, honest RAM, real swap, BSD images: why the virtualisation type decides what a VPS can run. KVM VPS from $5.49 list, $3.00 annual-eff.

Published 2026-08-30 · Updated 2026-10-10 · FYRHost Editorial · 18 min read

The spec sheet you compare hides the spec that decides

Buyers diff vCPU counts and clock speeds and skip the virtualisation line, yet that line decides whether your kernel, your swap, and your operating system images exist at all. Two plans with identical RAM and NVMe can behave like different products when the workload stops being a demo — one owns its kernel and swaps under pressure, the other shares a host kernel that reclaims memory the moment a neighbour spikes.

The industry splits into two families. OpenVZ and LXC put every tenant on the host's shared kernel, dividing memory as a burst-accounted pool that the host reclaims at will. KVM hands each server a real kernel of your choosing, with reserved RAM and its own swap. The monthly spread between the models at catalog prices is a few dollars — Sentry sits at $7.50 list — and the behavioural gap opens precisely where production begins: load, concurrency, and dependencies.

This catalog is KVM across the board — VPS, storage, and dedicated — for that reason, and the decision shows up in what you can mount: custom ISOs, BSD images, Windows, kernel versions you pick rather than inherit. Container shops cannot sell those at any price, because the product they run fundamentally does not have a per-tenant kernel to configure; the constraint is architectural, not a feature gap on a roadmap.

The typical mistake is shopping purely on dollars per gigabyte and discovering the platform's shape after the annual invoice: an iptables module missing, no swap present, a required kernel feature three years out of date. Those are not provider defects to ticket — they are properties of the technology the provider resells, and no support rotation will patch them, because patching would mean changing what every tenant on the host runs.

Which is why the rest of this guide walks the two families from the inside — what a shared kernel actually shares, what full virtualization hands you, where containers genuinely win — and ends with a verification procedure, because the spec that decides your workload is printed neither on the invoice nor the landing page, but in a command you can run yourself in ten seconds.

What a shared kernel actually shares

A container VPS does not share resources in the friendly sense — it shares the kernel, which is precisely the component you most want to control, and the host's memory manager owes your slice nothing the moment pressure appears. Namespaces give each tenant a private view of processes and mounts; cgroups meter what each may consume; but the scheduler, the memory reclaim logic, and the feature set all belong to one kernel that every tenant on the box depends on equally and controls not at all.

The namespaces(7) and cgroups(7) pages document the mechanism — isolation of view, metering of consumption — and OpenVZ layers its own accounting on top, visible in /proc/user_beancounters, where burst credits and failure counters accumulate after the fact. The model is efficient and dense, which is why it powered a generation of cheap hosting; density and guarantees pull in opposite directions, and the tenant sits at the short end of that trade.

The kernel freeze is the quieter limitation: features arrive when the host provider upgrades, not when your stack needs them. New syscall wrappers, eBPF capabilities, filesystem features — all inherit the host's version, and out-of-tree modules or DKMS drivers are structurally impossible, because loading a module into a shared kernel would change it for every tenant on the machine. Your uname -r reports someone else's release schedule.

The failure mode repeats across every container provider: an iptables module simply absent, a tunneling feature lacking the kernel side it needs, a debugging tool refusing to load — and the ticket comes back explaining, correctly, that the request would affect other customers. Those are architectural outcomes, not one bad provider having a bad week, which is why they never get fixed by escalation.

Understanding what is shared reframes the whole comparison — the question is never whether containers work, since they demonstrably do, but whether the kernel is yours or the house's, because every limitation in this section follows from that single ownership fact, and every advantage claimed for KVM in the next section is just the same fact pointed the other way.

What full virtualization hands you

The KVM list is short and concrete, and every item on it deletes a category of tickets rather than adding a feature: a kernel you choose, operating system images containers structurally cannot sell, swap that degrades latency instead of killing processes, and unrestricted container-in-VPS through full Docker and Compose. The KVM project documents the mechanism — hardware virtualization extensions turning the kernel into a hypervisor — but the tenant-visible summary fits in one sentence: the guest is a real machine.

A kernel you pick means custom builds, BPF tooling on current releases, DKMS drivers, and WireGuard without provider blessing — the WireGuard install page covers how current kernels ship it in-tree. Windows and BSD images boot like any guest, which container-only shops cannot offer at any price. Real swap means a memory spike costs milliseconds of latency instead of an oom-killer decision, and raw sockets mean packet tools behave like the documentation promises.

RAM honesty is the item people feel before they can name it: the 4 GB on Sentry is 4 GB of reserved ECC, not a slice of a contended pool with a burst credit attached. Order Sentry at $7.50 list — $6.00 on the annual term — and the memory your workload measures is the memory your workload owns, which changes capacity planning from folklore into arithmetic you can actually perform on a spreadsheet.

The failure mode here is subtle because it is an over-expectation: KVM does not make a small plan fast — it makes behavior predictable. Isolation is the product; speed arrives as a side effect of guarantees, not as a benchmark win. People who buy KVM expecting the container microbenchmarks to flip will be disappointed by single-digit-percent differences and miss the point entirely, which is the same mistake container buyers make, pointed the other way.

Read the list as deletions and it lands: no missing modules, no kernel version roulette, no burst-credit cliff, no images the platform cannot boot — full virtualization is less a faster VPS than a categorically quieter one, and quiet is what production workloads are actually buying when they pay the few dollars that separate the two families at catalog prices.

The oversold-container post-mortem, replayed

Ask anyone who ran a busy site on oversold OpenVZ and the story arrives unchanged: memory pressure hits the host, burst credits vanish, and the OOM killer picks your database even though your own usage graphs looked small. The post-mortem blames the provider; the mechanism says otherwise. On a shared, oversold kernel, one tenant's spike is every tenant's emergency, and the reclaim logic does not consult your feelings or your invoice tier.

The mechanism replays in three beats. A neighbour exceeds its fair share; the host's cgroup or OpenVZ accounting tries to reclaim; and when reclaim fails fast enough, the kernel kills the largest-looking victim rather than let the box thrash. Your /proc/user_beancounters shows failcnt increments after the fact — an autopsy report, not a shield. The OpenVZ wiki documents the accounting honestly; the density economics that make it cheap are the same economics that make your process the kill target.

The numbers explain the blast radius: on a 32 GB node hosting twenty tenants sold against burst, one runaway import can push gigabytes of reclaim pressure in seconds, and the victims are chosen by kernel heuristics, not by who caused it. A 2 GB plan with 2 GB of burst can die with 200 MB actually used, and the graph afterwards shows a flatline nobody can explain from their own metrics alone.

The failure response is as predictable as the failure: scale up within the same platform, which changes the size of the slice and not the shape of the knife. Ticketing does not fix it, monitoring does not fix it, and moving to a bigger container on the same oversold host is prepaying for the next incident with a higher invoice — the fix is the isolation boundary itself, which is a property of the platform, not the plan.

This is the section to remember when comparing monthly prices between a full KVM plan and a container special a few dollars cheaper — the discount is the price of standing next to strangers with a shared fire alarm, and the oversold variant of the story repeats at every provider that sells the same density, because it is not a policy any operator chose; it is what the architecture does under load.

Benchmarks: what the micro-numbers hide

Microbenchmarks give containers a small, real edge: a syscall on a container is a function call on the host kernel, while KVM adds a guest-host transition. That edge shows up as a few percent in tight syscall loops and vanishes the moment the workload does anything except spin in those loops — disk, network, locking, and concurrency drown the difference in noise a benchmark you cannot rely on under load has no business deciding purchases.

Where KVM does spend cycles is well-understood: virtualization exits on privileged operations and memory virtualization overhead, and on current EPYC and Xeon hosts with ECC memory, the cost sits at rounding-error scale next to the isolation it buys. The honest test is not a syscall loop but your real workload at real concurrency — watch tail latency under load, not single-thread scores, because p99s are where oversold neighbours and reclaim pressure show up and microbenchmarks never look.

Run the comparison like an engineer rather than a shopper: fio for storage patterns that match your actual write size, iperf3 for sustained network rather than ping, and the application itself under production-shaped traffic for a week if the decision is worth a week. The kernel KVM documentation explains the overhead mechanisms if you want the depth; for purchasing purposes, the actionable summary is that benchmark deltas under three percent measure the benchmark, not the platform.

The classic failure is choosing a container plan on the strength of a +3% syscall score, then losing hours of production throughput to throttling at peak — a trade nobody would accept if presented honestly as: a few percent of microbench speed in exchange for a nonzero chance that your database gets selected for death by someone else's memory spike. Framed that way the benchmark stops being an argument; framed on a comparison table it keeps winning purchases it should lose.

Benchmarks belong in the decision after the architecture is settled, as a tiebreaker between platforms that already guarantee what you need — because a number produced by a loop no workload runs, on a machine state no production system occupies, is not evidence about your future; it is evidence about the afternoon somebody ran a loop, and purchases deserve better evidence than that.

Verify the type yourself; labels drift

Sellers mislabel platforms — container specials marketed as cloud KVM appear regularly enough that the label deserves no trust, and the box itself will tell you the truth in one command. Verification takes ten seconds and should happen before the annual invoice, not after the first ticket, because everything else in this guide is downstream of what the command prints.

Run systemd-detect-virt: it answers kvm on a real virtual machine, none on metal, and identifies container environments — the systemd-detect-virt manual lists the full vocabulary. Cross-check with ls /proc/vz, which exists only on OpenVZ, and read lscpu for the hypervisor line. One of those outputs settles the family question on every platform this guide discusses, no vendor statement required.

Then verify the memory story, because it is where overselling hides: free -m shows swap — real KVM plans have it, container plans usually show zero — and a quick stress under load shows whether the 4 GB advertised is 4 GB reserved or 4 GB of pool with a burst credit and a reclaim timer attached. Swap present plus stable free output under neighbor load is the signature of honest allocation; the opposite signature is the oversold-container story waiting to happen.

The typical mistake is running the check after an incident, or running it and misreading a container answer as a provider lie rather than a product description — some vendors sell both families, and the listing you clicked may simply have been the other one. Either way the check is the arbiter: whatever it prints is what you bought, and arguing with the output has never once changed a kernel.

Ten seconds of verification converts the loudest part of this debate into a settled fact about your own machine — the family is known, the memory is measured, and the remaining decision is the ordinary one about whether those properties fit the workload, which is exactly where a purchasing conversation should start and, if you run the check first, where it can finally end.

Where containers are genuinely the right answer

The argument in this guide is against oversold shared kernels sold as VPS, not against containers — on hardware you control, LXC is an excellent tenancy tool, and saying so plainly is what separates a design opinion from tribal marketing. The LXC documentation describes the same namespace and cgroup machinery from earlier sections; what changes on your own metal is who sets the memory policy and who owns the kernel: you.

Fair uses are everywhere once the kernel question is settled: disposable CI runners where jobs are stateless by construction, homogeneous build fleets where one kernel version is a feature rather than a constraint, high-density appliance stacks on a dedicated box where the operator tunes reclaim behavior deliberately. OpenVZ historically powered a generation of affordable hosting for honest reasons — the density is real when the variance is managed by someone with an incentive to manage it well.

The difference is who bears the variance. On a dedicated machine running your own containers, you set the cgroup floors, you schedule the noisy jobs, and a neighbour's spike is your own batch process, killable by your own tooling. On an oversold shared node, the host's scheduler sets those priorities for you at the worst possible moment, and your options reduce to ticket, tolerate, or migrate — three bad choices at 3 a.m.

The failure to avoid is importing container economics onto rented shared kernels and calling it the same technology — a build farm design that works beautifully on your own 32-core metal gets reproduced on a $2 container special, and the design gets blamed for the outage. The KVM project and the LXC docs describe tools, not products; the product question is always who owns the kernel and who prices the density.

Grant containers their honest territory and the whole comparison gets calmer — kernels you control for anything with state, stakes, or a pager; shared-kernel density for workloads you can afford to treat as cattle — and the catalog distinction in the next section becomes what it should have been all along: a description of which tool the provider runs everywhere, rather than a trivia question hidden in the checkout flow.

What this catalog runs, and what that unlocks

Uniform KVM turns the purchasing decision into a pure size question: the five-tier ladder runs from Scout at $5.49 list to Sentinel at $33.50, the annual term takes 20% off, and the platform never changes under you as you climb. Scout carries 1 vCPU, 2 GB ECC, 40 GB NVMe on 1 Gbps; Ranger adds up to 4/8/120 on 2.5 Gbps; Sentinel tops out at 12/32/640 on 10 Gbps — no container fallback tier hides anywhere in the catalog.

Uniformity unlocks the platform features uniformly: custom ISO support for booting exactly the installer you want, nested virtualization on the VPS lines for labs and build matrices, and the kernel ownership described through this whole guide. Mount a custom ISO onto a Scout at $3.00 on the annual term and test the exact kernel you intend to run in production — the verification procedure from earlier sections, run before commitment, on hardware you are already paying pennies for.

The escalation path matters as much as the ladder: when the workload outgrows shared tenancy itself, the dedicated lineup answers with the same root over exclusive metal — Shield at $38.50 list, an E-2388G with 8 cores, 32 GB, and IPMI; Vault at $68.50 on a 16-core EPYC 7313; Bastion at $108.50 on a 32-core EPYC 7543 with 128 GB. The token-only checkout and the nineteen payment rails carry across the boundary, so growth never means re-onboarding.

The failure to avoid is buying size where the real need was isolation: a Sentinel slice for a workload whose actual complaint was a noisy neighbour is an expensive way to keep the disease, because the ladder tops out at tenancy boundaries and more slice does not change whose kernel sits under you. Metal is the next rung for a reason, and the reason is architecture, not capacity.

So the catalog's promise, stated plainly: one family everywhere, the ladder priced on hardware rather than hypervisor upsells, and an exit onto exclusive metal that preserves the credential, the payment rails, and the operational muscle memory — which is what the virtualisation type was supposed to decide all along, and what you should now be able to verify, price, and purchase without taking anyone's word for it.

The virtualisation check, in the order to run it

Before paying for anything longer than a month: run systemd-detect-virt on the box and believe the output — kvm means the guest is a real machine, a container answer means everything in the shared-kernel sections applies. Cross-check with ls /proc/vz and the hypervisor line in lscpu, because two cheap commands that agree are worth more than any landing page, and disagreement between them is itself the finding.

Second: verify the memory and swap story under load, not at rest. free -m at idle tells you what was allocated; a load test with a neighbour machine — or your own memory stress — tells you whether the allocation is reserved or burst-accounted, which is the difference between a latency dip and an OOM kill. Swap present and stable is the KVM signature; zero swap with a beancounter file is the container signature, and the two signatures predict incidents better than any review score.

Third: test the kernel features your stack actually needs — the module your tunnel wants, the eBPF tooling your observability uses, the filesystem your data prefers — because features are where shared kernels fail quietly. On KVM, boot the custom ISO or the kernel version you intend to run and confirm; a feature that loads in month one is a feature you can architect around, and one that cannot is a constraint you want on the table before the annual invoice, not after.

Fourth: run the real workload for a week and measure tail latency, not microbenchmarks — the comparison section explained why the loop scores lie, and a week of p99s under production-shaped traffic does not. Keep the exit path rehearsed while you evaluate: the migration guide turns a change of mind into a parallel run instead of an outage, which is what makes honest evaluation affordable in the first place.

Fifth and last: only now compare prices, because a number attached to the wrong architecture is a discount on the wrong product — family verified, memory proven, features confirmed, workload measured — and the backup pattern snaps on top of whichever platform passed, with snapshots where the platform offers them and the off-box leg carrying everywhere. The endpoint guide covers the one workload where the kernel question bites daily; the check, run in this order, answers it for everything else in under an hour.