When VPSLatch first sold a virtual server in 2010 it was OpenVZ, because that was what the market wanted at $4.46 a month. The move to KVM came later and cost more per customer. That trade-off has not gone away — it has just changed names. Here is what you are actually buying.
The one distinction that matters
Every virtualisation platform falls on one side of a single line: do you get your own kernel, or do you share the host's? Almost everything else follows from that answer.
| Full virtualisation (KVM) | Container (OpenVZ, LXC, Virtuozzo) | |
|---|---|---|
| Kernel | Yours. Boot what you like. | The host's, shared with every other tenant. |
| Kernel modules | Load anything | Only what the host has already loaded |
| Memory | Allocated to you, visible as real RAM | An accounting limit against a shared pool |
| Overselling | Hard to hide | Easy, common, and invisible from inside |
| Custom ISO / distro | Yes | Only the templates the host provides |
| Swap | Real | Usually simulated or absent |
| Overhead | A few percent | Almost none |
| Density for the host | Lower — so it costs more | Much higher — so it sells cheaper |
Why "1GB RAM" means three different things
On KVM, 1GB is 1GB. The hypervisor hands your guest that much memory and
free -m inside the guest tells you the truth.
On a container platform, 1GB is a ceiling enforced against a pool shared with everyone else on the node. If the provider has sold 64GB of "guaranteed" memory on a 32GB machine — which is trivial to do and impossible to see from inside — you get your gigabyte right up until the moment several neighbours want theirs simultaneously. Then the kernel's OOM killer starts choosing processes, and it does not ask you which ones you were using.
This is the actual reason cheap containers feel fine for months and then fall over inexplicably on a Tuesday. Nothing changed on your side. Something changed on the node.
Telling what you have
systemd-detect-virt # kvm, lxc, openvz, none…
uname -r # a vendor-patched kernel you did not choose is a hint
cat /proc/user_beancounters # exists on OpenVZ, absent on KVM
lscpu | grep Hypervisor
If systemd-detect-virt says kvm and uname -r shows a kernel
you installed, you have a real machine's worth of isolation.
Where containers are genuinely the right answer
Container virtualisation is not a scam. It has real advantages and the market share it holds is earned:
- Density, which is why it is cheaper. That saving is real and it is passed on.
- Near-zero overhead. No emulated hardware, no second kernel to schedule.
- Instant provisioning — seconds rather than a minute or two.
- Trivial resizing, often with no reboot at all.
For a staging box, a bot, a monitoring node or a personal service, a well-run container from an honest provider is a perfectly sensible purchase and you should not pay KVM prices for it.
Where it will bite you
- Docker. Nested containers on OpenVZ range from awkward to impossible depending on the host's kernel and configuration. On KVM it is just software.
- WireGuard and modern VPNs. These are kernel modules. If the host has not loaded it, you cannot, and no amount of configuration on your side changes that.
- nftables and modern firewalling. Container platforms frequently restrict which netfilter features you can reach.
- Custom kernels, custom distributions, custom ISOs. Not possible by definition.
- Anything memory-hungry and bursty. A database that occasionally wants a lot of page cache behaves very differently under a hard accounting limit.
The honest summary
Buy a container if the price difference matters and your workload is ordinary web software with predictable memory use. Buy KVM if you need your own kernel, if you are running containers of your own, if the workload is memory-sensitive, or if you simply want the provider's overselling to be constrained by physics rather than by their good intentions.
We sell KVM only, which is a commercial decision as much as a technical one: it is harder to oversell and therefore harder for us to quietly degrade your service to fit more customers on a node. Sometimes the useful thing about a technology is what it stops the vendor doing.