What is KVM? And is your server really running on it?

• It lives in the Linux kernel. KVM was added in Linux 2.6.20, released in February 2007. It is a kernel module (kvm.ko) plus one for the CPU maker, kvm-intel.ko or kvm-amd.ko.
• It uses the CPU’s own virtualization support. Intel VT-x and AMD-V let guest code run directly on the real CPU instead of being emulated instruction by instruction.
• A VM is just a process. The host’s kernel schedules each VM like any other program. Each virtual CPU is a thread taking turns on the host’s real cores.
• Each VM gets its own hardware, virtually. A network card, a disk, a graphics adapter, all private to that VM. It boots its own kernel, Linux or Windows.

QEMU can run without KVM, but then it emulates every instruction in software, which is slow. With KVM switched on, it uses the hardware. The kernel side is a small API: a program opens /dev/kvm, creates a VM, then creates virtual CPUs.

c=; grep -qa container=lxc /proc/1/environ 2>/dev/null && c=lxc
[ -f /.dockerenv ] && c=docker; [ -f /run/.containerenv ] && c=podman
{ [ -e /proc/vz ] && [ ! -e /proc/bc ]; } || [ -e /proc/user_beancounters ] && c=openvz
[ -z "$c" ] && c=$(systemd-detect-virt --container 2>/dev/null)
echo "container=${c:-none}"
echo "virt=$(systemd-detect-virt --vm 2>/dev/null)"
echo "hypervisor_flag=$(grep -c -w hypervisor /proc/cpuinfo)"
echo "nested=$(grep -m1 -o -wE 'vmx|svm' /proc/cpuinfo || echo no)"
echo "dev_kvm=$([ -e /dev/kvm ] && echo yes || echo no)"
echo "kernel=$(uname -r)"
echo "modules=$([ -e /proc/modules ] && echo yes || echo no)"
echo "tun=$([ -e /dev/net/tun ] && echo yes || echo no)"
echo "steal=$(awk '/^cpu /{t=0; for(i=2;i<=NF;i++) t+=$i; printf "%.2f", 100*$9/t}' /proc/stat)"

Why containers are checked first: inside our LXC container, systemd-detect-virt printed the outer machine’s type, not “lxc”. A container can only report what the host shows it, so the block looks for container markers before asking systemd.

Prefer to check by hand? lscpu shows it too. Ours prints Hypervisor vendor: KVM and Virtualization type: full.

On a container VPS, the “host kernel” is the provider’s, shared with every other customer on the machine. Inside LXC, changing a kernel setting with sysctl -w failed with “Read-only file system”.

What that changes for you:

• Software that needs kernel features may not install. mailcow, for example, doesn’t support OpenVZ, LXC or other container platforms. It supports KVM.
• VPNs need a TUN device or a kernel module. Neither container had /dev/net/tun. Our KVM server did, out of the box.
• Docker inside a container needs the host to allow nesting. On KVM it installs like on any Linux machine; our Docker tutorial ran exactly that way.
• Security is stronger on KVM. A VM adds a second boundary, the virtual hardware, so a kernel bug in one VM stays in that VM. In a container, a kernel bug can reach every container on the host.

1. Your CPU gets the CPU: low steal time

Your vCPUs are threads on the host. When more of them want to run than there are free cores, yours wait, and the kernel counts that wait as steal. Idle time is never counted, so a high number means you wanted the CPU and didn’t get it.

Our server has stolen 0.04% of its CPU time since boot (almost 5 days), and 0.15% under a full minute of 100% load. Check yours with vmstat 1, column st.

2. Kernel features built in

Every LiteKeep server boots a kernel with the features you need compiled in. WireGuard and overlay (for Docker) just work, with nothing to install or load. Keep the rest of the system patched with our unattended upgrades tutorial.

3. NVMe, DDoS filtering and 15 countries

Every server runs on NVMe storage, includes DDoS filtering, and costs the same in all 15 countries. Billed by the hour, never more than the monthly price.

Running mailcow? It needs at least 6 GB of RAM, so start on a Lite 6. For Docker, a VPN or a website, a Lite 2 is plenty.

Next steps, all tested on KVM: WireGuard on a VPS, Docker without breaking ufw, and the wider guide to choosing a VPS.