VPS, VM, and what's underneath

After trying to work out why one VPS (Virtual Private Server) costs twice as much as another with the same specs, I found the words describe how much of a machine you’re pretending to have, not what hardware you get. The question that resolves all of it is whose kernel it is.

VPS vs VM

VM (Virtual Machine) is a concept. VPS is a product.

  • VM: a virtual computer a hypervisor builds on a physical host. Run one on your laptop with VMware/VirtualBox/Parallels and nobody calls it a VPS.
  • VPS: a host company renting you one as a server, with vCPU, RAM, disk, a public IP, and an OS preinstalled.

EC2 / Azure VMs / GCE are the same thing with cloud furniture bolted on (IAM, VPC, load balancers, autoscaling, snapshots).

Every VPS is a virtualized server, but not every VPS is a full hardware VM. Some use KVM (full hardware virtualization). Cheap ones often use OpenVZ or LXC (container-based). That gap is the price difference.

Nobody owns the hardware, not even the VM

Host: 32 cores, 128 GB, SSD, NIC (Network Interface Card). Hypervisor slices it. VM A gets 4 vCPU / 16 GB / 100 GB / virtual NIC, VM B gets 8 vCPU / 32 GB, and so on.

Those vCPU and that virtual NIC are not a physical core or card set aside for you. They’re a virtual hardware interface. The silicon underneath stays shared.

So a VM owns a virtual hardware view and its own guest kernel. It does not own dedicated physical hardware. “VM” means a convincing illusion of a machine, running next to yours.

VM vs container: the kernel

The core distinction comes down to this: a VM brings its own guest kernel, while a container shares the host’s. We can catch it in the act inside an Ubuntu container:

cat /etc/os-release   # Ubuntu 24.04
uname -r              # the host's kernel, not yours

Userland is Ubuntu. The kernel belongs to the landlord.

How containers isolate

  • Namespaces = what you can see: PID, network (own interfaces, routing table, ports), mount, user, UTS (hostname), IPC, cgroup, time.
  • cgroups = how much you can use: CPU, RAM, process count, disk I/O, bandwidth. A provider can pin “2 cores, 2 GB, 500 procs, 50 MB/s, 100 Mbps” and enforce it.

A container doesn’t emulate hardware. It fences off processes and meters resources on a kernel it doesn’t own. That’s why it’s lighter than a VM.

OpenVZ / LXC vs Docker

Both are OS-level virtualization, but with different jobs.

  • Docker: application containers (Nginx, API, Redis, one each). Images, portability, fast starts, CI/CD, immutable deploys.
  • OpenVZ / LXC VPS: system containers. Look like a whole Linux server (SSH, systemd, long-running services), still share the host kernel.

Docker packages an app. OpenVZ/LXC gives you something shaped like a full Linux box.

Why the cheap ones are cheap

Containers skip the per-tenant kernel, full virtual hardware, boot process, and most memory overhead. More tenants per host, lower price.

The same efficiency is room to oversell: CPU oversubscription, memory overcommit, disk I/O contention, noisy neighbours. Performance on a packed host wobbles with what everyone else is doing. You’re buying your neighbours’ behaviour too.

What a container VPS costs you

  • No kernel swap. Any Linux userland you like, but the kernel is the host’s. No booting a different one, no arbitrary kernel boot params.
  • No kernel modules. modprobe loads into the host kernel, so it’s usually off-limits. Rules out some VPNs, special filesystems, storage / security / networking drivers.
  • Limited nested virtualization. KVM, a full VM, an Android emulator, a minikube KVM driver inside OpenVZ/LXC usually won’t run. The container never got real hardware virtualization to pass down.
  • Docker not guaranteed. Docker-in-container is nested containers, and it needs namespaces, cgroups, overlayfs, iptables/nftables, capabilities and nesting configured correctly. “Docker supported” on the page beats “Linux VPS.” Old OpenVZ or locked-down LXC trips on Docker networking, OverlayFS, systemd, cgroups.
  • WireGuard is the clean example. It’s in modern kernels, but that doesn’t mean your container VPS can run it. You still need a TUN device, the capability, the in-tree kernel module (or fall back to userspace wireguard-go), and the right permissions. Kernel support is necessary, not sufficient, and on a shared kernel that phrase covers most of your problems.

Security, briefly

VM: an intruder is in a guest with its own kernel and still has to beat the hypervisor to reach the host or other tenants.

Container: everyone shares one host kernel. A kernel vuln, container escape, capability misconfig, or privileged-container abuse can in theory reach the host and the neighbours.

That isn’t “containers are insecure.” Big platforms run them everywhere, with seccomp, AppArmor, SELinux, dropped capabilities, non-root containers, read-only filesystems, patched kernels, gVisor / Kata / microVMs. On a two-dollar VPS you can’t verify any of that, so KVM is the conservative bet.

”Dedicated” hides the layer

  • Dedicated server / bare metal: a whole physical machine, one customer. You touch CPU, RAM, disk, NIC, OS, kernel, hypervisor. Means what it sounds like.
  • Dedicated host: a physical box running only your VMs. Still VMs. Used for license compliance, tenancy isolation, regulatory, placement control.
  • Dedicated vCPU: scheduling that isn’t fighting other general tenants, or a firmer vCPU guarantee. Not a whole machine, not a socket, not exclusive RAM/disk/NIC.

When a page says “dedicated,” ask at which layer.

The stack

Bare Metal (Physical Host)
├── Hypervisor ──> Virtual Machine (KVM VPS) ──> Guest Kernel ──> Userland / Docker / Apps
└── Host Kernel ─> System Container (LXC VPS) ──────────────────> Userland / Apps

VM and container both, almost always, mean shared physical hardware.

Detecting what you’re on

Product page: KVM vs OpenVZ / LXC / Xen / VMware / Hyper-V.

Inside the box:

systemd-detect-virt      # kvm | openvz | lxc | vmware | xen
hostnamectl
lscpu
dmesg | grep -i hypervisor
virt-what

Providers can hide some of this, so the docs still matter.

Which one to pick

For Docker, AI agents (OpenClaw, Hermes Agent, that kind), general backends, networking labs, VPN, anything long-running I care about: KVM VPS.

Container VPS is fine and cheaper for small sites, Nginx, WordPress, a personal API, Node/Python services, Telegram/Discord bots, cron jobs, learning Linux. The rule: does it need any control over the kernel? If not, take the cheap box.

Listing checklist, roughly in order: KVM; Docker explicitly supported; root; TUN/TAP; IPv4 + IPv6; CPU shared vs dedicated; disk local SSD/NVMe vs network storage; snapshots/backups; bandwidth caps; SMTP/VPN/proxy/port blocks; nested virtualization allowed; fair-use / CPU-throttling rules.

VM and container both share the physical hardware. The difference is the kernel: a VM brings its own, a container borrows the host’s and only fences off processes, filesystem, network and resources. The only thing that hands you real metal is bare metal.

← prev postnext post →