KVM vs OpenVZ vs LXC — Why the Virtualisation Type Matters

What separates KVM from container VPS: own kernel, swap, custom modules, Windows images, fair isolation. Why BitCloudVPS sells KVM only.

Published 2026-08-30 · Updated 2026-10-21 · BitCloudVPS Editorial

Containers vs virtual machines

OpenVZ/LXC are containers: every VPS shares the host’s kernel, and “RAM” is a pool with burst accounting that evaporates under load. KVM is a true virtual machine: a real kernel of your choice, real swap, dedicated memory the host cannot reclaim. The price difference is a few dollars; the difference in behaviour shows up exactly when your workload matters.

What KVM gives that containers cannot

• Any kernel: custom builds, BPF tooling, kernel modules ( WireGuard, DKMS drivers).
• Windows and BSD images — containers are Linux-only by design.
• Real swap — memory spikes degrade gracefully instead of hard-failing.
• Docker-in-VPS without restrictions, nested virtualisation on request, RAW sockets for packet tools.
• Honest RAM — 4 GB is 4 GB, not 4 GB shared with forty neighbours.

The failure modes of oversold containers

Classic OpenVZ symptoms: the host hits memory pressure and your process gets the OOM kill despite “your” usage being small; a kernel feature you need simply does not exist; iptables modules are missing. These are not provider bugs — they are the architecture. KVM removes the class of problem.

Short answer: why this difference decides what you can run

Short answer: KVM gives every tenant its own kernel on virtual hardware; OpenVZ (and Virtuozzo, and LXC) gives tenants containers that share one kernel. Everything practical follows from that sentence. On KVM you can load kernel modules, run your own kernel version, use Docker and other nested virtualization patterns, run distros whose userland expects a different kernel than the host's, and tune sysctl without asking anyone. On OpenVZ you can run only what the host kernel supports, and the host kernel is one account for everyone on the machine.

BitCloudVPS is KVM across the catalog - every VPS plan from Nano at $5.49/mo to Max at $60/mo runs on KVM with ECC RAM and NVMe storage - and this guide covers why that is not a marketing preference but an operational boundary: what KVM enables that containers cannot, how oversold containers actually fail, how to detect what a VPS you already rent is running, and where containers are legitimately the better tool so the comparison stays honest.

What a shared kernel takes away from you, itemized

Container tenants hit the wall in the same five places, and each one tends to arrive as a surprise mid-project rather than at signup.

1. Kernel version and modules. WireGuard, newer BPF features, specific iptables modules, filesystem modules - if the host did not build it in, you cannot load it: modprobe fails with permission errors.
2. sysctl control. Network stack tuning (net.core.*, BBR congestion control, conntrack limits) is either namespaced-away or globally shared; a neighbor changing it changes yours.
3. Docker and friends. Docker on OpenVZ means matching the host kernel's container support and a specific veth configuration; on many builds it simply refuses, and nested containers degrade further.
4. Distribution freedom. A Debian 12 userland on a host kernel from 2019 produces subtle breakage - systemd features failing quietly, glibc warnings, occasional segfaults under load.
5. Resource honesty. vSwap and beancounters report memory differently from real kernel accounting, which is why a container that "has 4 GB" can OOM while free shows plenty.

None of these are exotic requirements. WireGuard, Docker and BBR are 2026 defaults for most workloads, which is why the shared-kernel model keeps shrinking to its niche: cheap bulk hosting where tenants do nothing but run a web root.

How oversold containers fail: the failure modes, in order

Overselling is the business model that cheap OpenVZ pricing is built on, and it fails in characteristic patterns. A KVM host can oversell CPU time too, but the container model adds failure modes that make the cheap tier behave worse under load than any spec sheet shows.

The tell for all five is intermittency that correlates with other people's peak hours. If a $2-3 container is fast at 09:00 and unusable at 21:00, you are reading neighbor load, not your own.

Detect what your current VPS is running, in four commands

If you inherited a server or signed up somewhere on price alone, establish the virtualization type before you plan anything on it. Four commands, no privileges needed beyond root:

1. systemd-detect-virt - prints kvm, qemu, openvz, lxc, or none on bare metal. This one answer settles the question on systemd distros.
2. ls /proc/vz - if it exists (often as /proc/vz/veinfo or bc/), you are in an OpenVZ container even when marketing said "VPS".
3. dmesg | grep -i hypervisor or lscpu | grep Hypervisor - names the hypervisor family on KVM-class systems.
4. cat /proc/user_beancounters - OpenVZ's resource accounting file; its presence is a fingerprint, and its limits show you exactly which beancounters the host has capped.

Interpretation is binary for planning purposes: kvm means the rest of this desk's guides work as written - modules, Docker, sysctl, your own kernel. openvz or lxc means read them as advisory only, and expect at least one of WireGuard, Docker or kernel tuning to be unavailable. Migrating off a container to a KVM box is the same staged rsync procedure as any other move.

Where OpenVZ is genuinely the right tool - the honest column

A comparison that never concedes anything is marketing, so here is what the container model does better. Startup density is the headline: a container boots in seconds and costs the provider almost nothing to schedule, which is why $2-3 price points exist at all. For a disposable build target, a throwaway VPN endpoint you rebuild weekly, or a batch of scratch environments where shared-kernel isolation is acceptable, that price is real value. Memory efficiency is the second honest win: no per-VM kernel overhead means a 512 MB container runs a small web root comfortably where a 512 MB KVM guest spends ~80-150 MB on its own kernel.

The trade you accept is categorical, not incremental: everything in the itemized section above - kernel modules, Docker, sysctl, distribution freedom, honest isolation - goes away the moment you choose the cheap tier. BitCloudVPS does not sell the container tier, and the reason is that the catalog's core promise (root access you can actually use, no questions asked) breaks silently on a shared kernel: a tenant who cannot load a module or run Docker did not get the machine they paid for. If your workload survives on a container, stay there and pocket the savings; if it needs any of the five walls, KVM from $5.49/mo on Nano is where the honest floor sits.

Getting the most from a KVM plan: what you control inside the guest

KVM hands you a kernel; using it well is a short list of tunables that outperform any plan upgrade at the margin.

1. Congestion control: sysctl -w net.ipv4.tcp_congestion_control=bbr plus net.core.default_qdisc=fq measurably helps latency-sensitive transfers, especially on transatlantic routes from Ashburn or Dallas.
2. Filesystem: mount NVMe volumes with noatime; confirm the SSD scheduler (cat /sys/block/vda/queue/scheduler, prefer none or mq-deadline on NVMe-backed guests).
3. Conntrack: raise net.netfilter.nf_conntrack_max for busy proxies - on KVM the table is yours, so tuning it is permanent, not a negotiation with neighbors.
4. Docker: runs natively; enable it with the standard install and keep the daemon's log driver sized (max-size: 10m) or logs will eat the NVMe allocation in weeks.
5. Kernel updates: apply them on your schedule with unattended-upgrades for security and manual reboots for kernel majors - your uptime, your calendar.

Verify each change survived the next reboot; sysctl settings belong in /etc/sysctl.d/99-local.conf, not just the live tree.

Kernel, hypervisor and what a plan label actually promises

The direct answer: KVM gives every plan its own kernel and a real virtual machine boundary; OpenVZ and other container virtulators share the host's kernel and ration it with per-container limits. Everything else in the comparison — module support, swap behavior, density, price per gigabyte — follows from that one architectural fact.

Why it matters for what you can run: inside KVM you load the kernel modules you need, run your own sysctl policy, use real swap, run Docker and other nested containers without fighting the host, and even run another hypervisor inside for lab work, within plan resources. Inside a shared-kernel container, none of that is yours: the kernel belongs to the host node, so a module the provider did not load is a module you cannot have, and one noisy neighbor's fork bomb or disk flood is a kernel event your whole node feels.

What the label promises, in catalog terms: these plans are KVM on EPYC 7443P-class hosts — Nano from $5.49/mo (flat $36/yr), Starter $8.50 with 2 vCPU and 4 GB ECC, up through Max at $60 — each with NVMe, ECC, an unmetered 1-10 Gbps port, one IPv4 and a /64 of IPv6. ECC matters more than usual in a virtualization argument: it is the host's protection against silent memory corruption, and it is on every tier rather than being a premium feature.

How to verify the claim on any host, ours or anyone's: after deploy, check that systemd detects hardware virtualization, that you can read dmesg as your own kernel's boot log, and that kernel version matches what you would expect from your chosen distribution — not the provider's. If uname and the boot messages disagree with your OS image, you are in a container wearing a KVM label. Run those three checks before paying for any annual term; they take two minutes and settle the question for good.

How oversold containers fail, and what a KVM boundary changes

The direct answer: oversold container hosts fail in characteristic, diagnosable ways — burst credit cliffs, steal you cannot see, swap theft — because limits are enforced inside a shared kernel that everyone on the node is fighting for. On a KVM plan the same overcommit exists at the host level, but the failure surfaces as your own measurable CPU steal instead of as silent, unexplainable throttling of processes you never touched.

The failure modes, in the order you meet them. First, the RAM mirage: container plans advertise generous memory because unused pages can be double-sold; the day two tenants actually use their allocation, the node's oom-killer picks victims by its own policy, not yours. Second, burst accounting: a container CPU quota that reads as '4 cores' in a panel can be a fraction of a core sustained, which you discover when a compile, a database index build or a nightly backup gets stretched tenfold. Third, kernel-side contention: io pressure on the shared filesystem lands on everyone simultaneously, so your 'NVMe' latency spikes exactly when a neighbor runs theirs. Fourth, no-swap designs: with the kernel shared, swap is often disabled globally, so one memory spike turns into process kills instead of slowness.

Diagnosing which world you are in, from inside: steal visible in top means a hypervisor owes you cycles; a kernel that will not accept your sysctl or module changes means the kernel is not yours; swap that refuses to enable means the design assumes overcommit. All three checks are one command each and are worth running on any box you inherit.

On this catalog the boundary is structural, not aspirational: KVM plans, ECC everywhere, NVMe on real virtual disks, and the port (1-10 Gbps unmetered) is yours to saturate without a neighbor's traffic shaping it. That is also why container-style 'more RAM per dollar' listings elsewhere cost what they cost.

Choosing between container and VM plans: a decision procedure

The direct answer: choose KVM unless you have a specific, current reason to want a shared-kernel container — density for throwaway task boxes being the only common one. The decision takes a minute and saves the migration you would otherwise do in six months.

Walk the list. Do you run, or might you run, Docker or any nested container stack? KVM — nested containers are ordinary software there. Do you need a specific kernel, module, or tuning — a wireguard module, BPF tooling, custom sysctls? KVM; the kernel is yours. Does the workload have state you care about — a database, user uploads, mail? KVM, for real swap and predictable memory. Is it a short-lived, stateless task runner where you would trade all of the above for the cheapest possible gigabyte? That is the one case where a container plan's density argument holds — and even then, note that Nano at $5.49/mo, or $36/yr flat, is close enough to container pricing on this network to make the argument thin.

Sizing on the KVM side, so the decision includes the tier: Starter ($8.50, 2 vCPU, 4 GB ECC, 60 GB NVMe) carries a small service with a database; Plus ($13.50) is the middle for anything busier; Business ($30, 6 vCPU, 16 GB, 240 GB NVMe, 5 Gbps) is where a stack of containers stops feeling rationed; Pro and Max ($45/$60) exist for the point where you would otherwise shard. The Storage line ($24-$56, 1-5 TB) answers a different question entirely — capacity, not compute — and the dedicated ladder from $79.50 answers the one after that.

Verification habit, whichever you pick: after the first deploy, run your real workload shape — the peak, not the average — for a week on a monthly term before any annual commitment. Terms discount nicely (quarter −10%, year −20%), but the discount is only a win if the plan was right; the monthly term is the cheapest way to find out.

Tuning inside the guest: recovering the performance a KVM plan promises

The direct answer: on a KVM plan the guest is yours end to end — kernel, userspace, disk layout, network stack — so the ceiling on performance is set by your configuration far more often than by the virtualization. A few deliberate settings recover most of what people leave on the table.

Disk: NVMe behind a virtio interface rewards an I/O scheduler meant for fast devices (none, or mq-deadline) and a filesystem mounted with sensible options for your workload — relatime and noatime for the volumes that do not need access times. Databases want their data on their own filesystem so you can tune them separately from the OS. Memory: with ECC underneath and real swap available, set swappiness to match the service — low for a latency-sensitive database that should never page, higher for a cache-heavy box where paging idle objects out is a win. CPU: pin nothing until you have measured; on EPYC hosts the scheduler usually does better than hand-tuned affinity, but do check steal under load so you know the baseline is honest.

Network: the port is unmetered at 1-10 Gbps depending on plan, and the /64 IPv6 block is yours to subnet — one address per service makes firewall rules and logs readable, which is a performance benefit in an emergency. Enable the NIC's multiqueue if the image does not, and test with iperf3 against a nearby location before concluding anything about throughput; Amsterdam to Frankfurt is ~8 ms, so latency is not the excuse there.

Troubleshooting corner, KVM-specific: a guest that boots slowly is usually waiting on cloud-init or entropy, not disk; disk latency complaints deserve an fio profile of your actual access pattern, not a single random-4k number; and if nested Docker inside the VM cannot reach the network, the fix is in your own iptables/NAT rules — the hypervisor is not involved. When the box itself is the constraint, the path up the plan ladder is a reboot away, and the catalog holds reserved capacity rather than asking you to re-platform.

The seven checks that separate no-KYC hosts, October 2026 edition

Compare candidates on facts, not vibes: (1) ECC RAM or consumer DIMMs; (2) local NVMe versus network-attached disk; (3) unmetered port speed and what the burst ceiling really is; (4) DDoS filtering included or sold as an add-on; (5) how many jurisdictions the rack map actually covers — twenty-one here, including Reykjavik, Bucharest, Shanghai; (6) checkout depth — 19 checkout assets — BTC, XMR, ETH, SOL, LTC, TRX, XRP, DOGE, DASH, ADA, GRAM (TON) and USDT on 7 networks, token-only signup, no KYC; (7) provisioning time in writing. This line passes all seven: Nano $5.49 (1 vCPU / 2 GB ECC / 40 GB NVMe; flat $36/yr = $3/mo effective), Starter $8.50 (2 vCPU / 4 GB DDR4 ECC / 60 GB NVMe), Plus $13.50 (4 vCPU / 8 GB DDR4 ECC / 120 GB NVMe), Business $30 (6 vCPU / 16 GB DDR5 ECC / 240 GB NVMe), Pro $45 (8 vCPU / 24 GB DDR5 ECC / 400 GB NVMe), Max $60 (12 vCPU / 32 GB DDR5 ECC / 640 GB NVMe); dedicated boxes from Start $79.50 (Intel Xeon E-2388G, 32 GB DDR4 ECC) to Ultra $449.50 (2 x AMD EPYC 9474F / 3.6-4.1 GHz, 512 GB DDR5 ECC-R), all with IPMI and DDoS scrubbing. Rival-by-rival alternatives. The no-KYC baseline. Honest limits: we publish our own sheet, rival specs are quoted from their sites and can change without notice — re-check any number before sending crypto anywhere, including here.