How KVM works under the hood
KVM converts the Linux kernel into a Type-1 hypervisor by exposing a /dev/kvm character device. A user-space process (typically QEMU) opens that device, asks the kernel to create a virtual CPU, and then runs guest instructions directly on the physical CPU using hardware virtualization extensions. The kernel handles privileged events; everything else executes at native speed.
Three components make KVM work. First, the kvm.ko kernel module manages CPU and memory virtualization and exposes the /dev/kvm interface. Second, an architecture-specific module — kvm-intel.ko for Intel VT-x or kvm-amd.ko for AMD-V — translates between the generic KVM API and the underlying CPU's virtualization instructions. Third, a user-space hypervisor process such as QEMU, cloud-hypervisor, or Firecracker provides the device emulation: virtual disks, NICs, USB controllers, and BIOS or UEFI firmware. Because the Linux kernel itself is the hypervisor, every Linux scheduler, memory manager, and security feature applies to VMs the same way it applies to native processes. A KVM guest is simply a heavyweight process from the kernel's point of view, which is why tools like top, perf, and cgroups work on it without modification.
KVM vs OpenVZ vs VMware ESXi vs Hyper-V
KVM provides full hardware virtualization with a separate guest kernel for every VM. OpenVZ uses OS-level containerization where every container shares the host kernel. VMware ESXi is a proprietary bare-metal Type-1 hypervisor with its own kernel (VMkernel). Hyper-V is Microsoft's Windows-based Type-1 hypervisor. Only KVM, ESXi, and Hyper-V give you a real, isolated guest kernel.
OpenVZ (and its successor Virtuozzo) is a container technology, not a hypervisor. Every OpenVZ container shares the host's Linux kernel, which means you can't run a different kernel version, you can't load custom kernel modules, and you can't run a non-Linux operating system. The trade-off is density: because there's no per-VM kernel overhead, an OpenVZ host can squeeze more containers onto the same hardware, which is why low-end shared-VPS plans frequently used it. VMware ESXi is the enterprise standard for Type-1 virtualization but ships as a closed-source product with per-socket licensing that historically priced it out of commodity VPS hosting. Hyper-V dominates Windows-server environments and integrates tightly with Active Directory and System Center but is a less common choice for Linux-heavy hosting fleets. KVM has become the default for modern VPS hosting because it is open source, kernel-mainlined, supports any guest OS that runs on x86_64 or aarch64, and has a mature management ecosystem (libvirt, oVirt, Proxmox, OpenStack Nova).
Why KVM is the modern default for VPS
KVM became the dominant VPS technology because it gives every customer a real, isolated kernel without paying VMware-style licensing. It supports Linux, Windows, BSD, and Solaris guests, runs on commodity x86_64 and ARM hardware, and is integrated into every major cloud orchestration stack — OpenStack, Proxmox VE, Kubernetes via KubeVirt, and AWS Nitro all build on it.
Three forces converged to make KVM the standard. First, hardware virtualization extensions became universal: Intel VT-x shipped in Core 2 chips in 2006 and AMD-V in early Athlon 64s, so by the early 2010s essentially every server CPU could host KVM at near-native speed. Second, the Linux community refused to adopt Xen-style paravirtualization in mainline, but mainlined KVM in 2007, instantly giving every distribution a built-in hypervisor. Third, the public cloud ecosystem invested heavily: Google Cloud Engine launched on KVM, AWS migrated from Xen to a KVM-based Nitro architecture, and OpenStack standardized on KVM as the reference hypervisor. Smaller VPS providers benefit from this gravitational pull because the same tooling that runs hyperscaler fleets — libvirt, virtio drivers, cloud-init — also runs on a single rack of commodity servers.
Real performance characteristics: CPU steal, IO, and overhead
On a properly provisioned KVM host, expect single-digit-percent CPU overhead versus bare metal, sub-millisecond network latency added to local-network paths, and 80-95% of native disk IOPS when virtio-blk or virtio-scsi is used with a paravirtualized driver. CPU steal time above 5% sustained is the canonical sign of host overcommit and a strong upgrade signal.
Three numbers matter for a KVM guest in production. CPU steal time, exposed in /proc/stat as the eighth field, measures the percentage of time the virtual CPU was ready to run but the physical CPU was busy executing other guests. Anything below 1-2% is normal background noise; sustained values above 5% mean the host is overcommitted and your workload is being throttled. IO wait, surfaced by tools such as iostat and top, measures the percentage of time the CPU spent blocked on disk or network. With virtio paravirtualized drivers and modern NVMe backing storage, sustained IO wait above 20% on a workload that should be CPU-bound is a strong sign the disk subsystem is saturated. Network throughput on virtio-net should reach 80-95% of the physical NIC's line rate; anything materially below that points to a misconfigured offload or an old emulated e1000 driver.
When NOT to use KVM
KVM is the wrong choice in three situations: ultra-high-density containerized workloads where per-VM kernel overhead dominates, Windows-licensing-sensitive deployments where Hyper-V's SPLA pricing is materially cheaper, and certain low-latency hardware-passthrough scenarios where SR-IOV or GPU passthrough is poorly supported on your specific NIC or GPU model.
For containerized microservices that don't need kernel isolation, Linux containers (Docker, Podman, Kubernetes) running directly on bare metal will out-pack any KVM-based VPS by 3-5x because each container is just a process group with namespaces and cgroups. Density-sensitive low-cost VPS providers historically chose OpenVZ for the same reason. Windows-heavy deployments — particularly those running Windows Server licenses purchased through SPLA — sometimes pay materially less on Hyper-V than on KVM because of how Microsoft prices guest licenses on competing hypervisors. Finally, certain hardware-passthrough scenarios are still painful on KVM: GPU passthrough requires IOMMU groups to be cleanly isolated, some consumer NICs don't have SR-IOV support, and PCIe passthrough of NVMe drives sometimes triggers reset-bug workarounds. For 95% of general-purpose Linux VPS workloads, none of these apply and KVM is the correct default.
How to verify a VPS is really KVM-based
Inside a Linux guest, run `systemd-detect-virt` — it should print `kvm`. Cross-check with `lscpu` (the 'Hypervisor vendor' line should read 'KVM') and `dmesg | grep -i kvm`. If you see 'OpenVZ', 'lxc', or 'VMware' instead, your provider is using a different technology even if marketing claims otherwise.
Before signing a contract, run a small diagnostic battery on a trial VPS. Run `systemd-detect-virt` for the canonical detection output. Run `cat /proc/cpuinfo | grep -E 'vmx|svm'` to confirm hardware virtualization extensions are passed through (some providers strip them, breaking nested virtualization). Run `uname -r` to verify you're seeing a guest-specific kernel rather than a shared host kernel — on a real KVM VPS you can install a different kernel via `apt install linux-image-...` or `dnf install kernel-...` and reboot into it. On OpenVZ you cannot. Finally, check `/proc/user_beancounters` — if that file exists, the host is running OpenVZ regardless of what marketing copy says.