KVM Virtualisation Explained

Published on | Updated

Not all virtualisation is equal. KVM gives each VPS its own kernel and near-bare-metal performance. Here's what that means for your workloads.

Server racks behind mesh doors, with orange and blue network cables and green status lights When you buy a VPS, you are buying a slice of a physical server accessed through virtualisation. The type of virtualisation matters enormously for performance, security, and resource guarantees.

What is KVM?

KVM (Kernel-based Virtual Machine) is a Linux virtualisation technology built directly into the kernel. Each KVM virtual machine runs as a full operating system with:

  • Virtual CPU cores (vCPUs) that run on the host's physical cores, usually shared with the other VMs on the host unless the provider pins or dedicates them
  • Allocated memory that is actually reserved, not shared
  • Isolated storage
  • Its own kernel (you can run any OS, any kernel version)

KVM vs. OpenVZ vs. LXC

FeatureKVMOpenVZLXC
Full OS isolation✅❌Partial
Custom kernel✅❌❌
Dedicated RAM✅BurstableBurstable
PerformanceNear-bare-metalGoodGood
Docker support✅Limited✅

OpenVZ and LXC containers share the host kernel. This limits what you can run (no custom kernel modules, restrictions on some system calls). KVM VMs are fully isolated: if the host runs Debian, your KVM VM can still run Ubuntu, AlmaLinux or Windows with its own kernel.

Why KVM Performance Matters for Specific Workloads

Databases: MySQL, PostgreSQL, and MongoDB rely on direct memory access and disk I/O. KVM's reserved memory stops another VPS on the same host from eating into your RAM. Disk and CPU are still shared on the host, so fast NVMe storage and some CPU headroom matter.

Game servers: Minecraft, Rust, and FiveM want consistent, low-latency CPU access. CPU pinning (tying a VM's vCPUs to specific physical cores) reduces the variation you get when many guests compete for the same cores. Whether a provider pins cores is their choice, so ask.

Compilation and builds: CPU-intensive tasks run at near-native speed on KVM. OpenVZ throttles burst CPU usage.

Verifying You Have KVM

# Run on your VPS:
systemd-detect-virt
# Should return: kvm

# Or:
lscpu | grep -i hypervisor
# Should show: Hypervisor vendor: KVM

You will often see grep -E "vmx|svm" /proc/cpuinfo suggested for this. That check tells you whether your VM can run virtual machines itself (nested virtualisation), not whether it is a KVM guest, so an empty result on a KVM VPS is normal.

Space-Node VPS plans run on KVM in the EU with NVMe storage and dedicated RAM; the vCores are shared with the other VPSes on the node. Standard runs an AMD EPYC 7452 and Premium a Ryzen 9 9950X. Premium can be ordered from €4.20 a month and Standard from €4.99 a month.

See the Space-Node KVM VPS plans

What KVM actually does to your performance

KVM is a kernel module that turns Linux into a type-1.5 hypervisor. Each VM is a regular qemu process talking to KVM via /dev/kvm. CPU instructions run on bare hardware (Intel VT-x / AMD-V); only privileged operations are trapped.

Where the overhead shows up, roughly in order:

AreaWhat costs performanceWhat fixes most of it
CPUVery little for normal code, because guest instructions run directly on the hardwarehost-passthrough so the guest sees the real CPU features
StorageEmulated disks, and host page caching layered under the guest's own cachevirtio disks, raw images, cache='none', async I/O
NetworkEmulated network cardsvirtio-net with vhost

Storage is usually where a badly configured VM loses the most. How much depends on the host, the disks and the settings, so if it matters for your workload, run the same fio or sysbench job on the VPS and on a machine you trust and compare the numbers yourself.

Settings that bring KVM close to bare metal

<cpu mode='host-passthrough' check='none'>
  <topology sockets='1' cores='4' threads='2'/>
  <feature policy='require' name='topoext'/>
</cpu>

<disk type='file' device='disk'>
  <driver name='qemu' type='raw' cache='none' io='io_uring' discard='unmap'/>
  <source file='/var/lib/libvirt/images/vm.raw'/>
  <target dev='vda' bus='virtio'/>
</disk>

<interface type='network'>
  <model type='virtio'/>
  <driver name='vhost' queues='4'/>
</interface>

Settings that matter most:

  • host-passthrough exposes the real CPU features (AVX2, and AVX-512 on Zen 4 and Zen 5) instead of a generic model.
  • cache='none' io='io_uring' removes a layer of host page cache and uses async I/O.
  • virtio everywhere; emulated devices such as e1000 or IDE are much slower.

When KVM is the wrong choice

NeedPick
Lowest possible MSPT for one Minecraft serverbare metal
GPU passthrough for live transcodingKVM with VFIO (works)
Deny noisy neighborsKVM with CPU pinning
Hundreds of small servicesLXC / Docker, lighter than KVM
Run Windows safelyKVM with virtio-win drivers

Numbers for ordering decisions

If you see a "VPS" priced 50 % below the equivalent bare metal node and the provider runs OpenVZ or shared-tenant LXC: that's not a real KVM VPS. It shares RAM as well as CPU with the other tenants, and that shows up at peak hours. Always confirm in writing that you get KVM, how the vCores are shared and whether the RAM is dedicated to you. Our guide to shared vCPU vs dedicated CPU explains what shared vCores mean in practice and which workloads need dedicated cores.