What Is a VPS Hypervisor? The Software Layer That Makes Cloud Hosting Possible

Every time you spin up a VPS, you are renting a slice of a physical server that is simultaneously running many other virtual machines for many other customers. The technology that makes this possible — and that keeps each of those virtual machines isolated from one another — is the hypervisor. It is one of the most important pieces of software in modern computing infrastructure, and yet most people who depend on it daily have never thought about it directly.

This matters in practice because not all hypervisors are equal. The hypervisor your provider uses determines how well your CPU cores are isolated, how faithfully your RAM allocation is guaranteed, how your storage performs under concurrent tenant load, and whether features like dedicated vCPU pinning are even possible. Choosing a provider on price alone, without considering the underlying virtualisation platform, is a bit like buying a house without checking what it is built on.

What a Hypervisor Actually Does

The word hypervisor comes from “supervisor” — a term from early computing for an operating system’s privileged management layer. A hypervisor is a supervisor of supervisors: software that manages multiple operating systems simultaneously on a single physical machine.

Its core responsibilities are resource partitioning and access mediation. The hypervisor takes a physical server’s CPU cores, RAM, network interfaces, and storage — including fast NVMe drives where available — and divides them into isolated pools assigned to each virtual machine. When a VM’s OS kernel issues a hardware instruction, the hypervisor intercepts it, validates it, and either executes it on the physical hardware on the VM’s behalf or returns a virtualised result. This interception layer is what prevents one VM from reading another VM’s memory, monopolising the CPU, or interfering with storage belonging to a different tenant.

The hypervisor also manages what happens when VMs compete for the same physical resources. When multiple VMs want CPU time simultaneously, the hypervisor’s scheduler decides who gets it and for how long. This scheduling behaviour is what distinguishes a shared vCPU environment — where many VMs time-share the same physical threads — from a dedicated vCPU environment where the hypervisor pins specific threads exclusively to one VM.

Type 1 vs. Type 2 Hypervisors

Hypervisors are broadly classified into two categories based on where they run in the software stack.

Type 1: Bare-metal hypervisors

A Type 1 hypervisor runs directly on the physical hardware, below any general-purpose operating system. It is the first piece of software the server boots into, and everything else — including any management operating system — runs as a guest on top of it. Because there is no host OS between the hypervisor and the hardware, Type 1 hypervisors have direct access to all physical resources and can manage them with minimal overhead.

Xen and VMware ESXi are canonical Type 1 hypervisors. Both boot directly on server hardware and present a management interface through a privileged domain (Xen calls this Dom0; ESXi uses its own management console). KVM is also classified as Type 1, though its architecture is distinctive: rather than replacing the host operating system, KVM converts a standard Linux installation into a hypervisor by loading a kernel module that gives the Linux OS kernel hypervisor capabilities. The host Linux system then runs as a privileged VM alongside its guests.

Type 2: Hosted hypervisors

A Type 2 hypervisor runs as an application on top of a conventional host operating system. The host OS mediates all hardware access, and the hypervisor layer sits above it. VirtualBox and VMware Workstation are common examples. Type 2 hypervisors introduce an additional layer of overhead because every hardware call from a guest VM must pass through both the hypervisor and the host OS kernel. They are suitable for desktop virtualisation and development environments but are not used in production cloud hosting because of this performance overhead.

The Major Hypervisor Platforms: KVM, Xen, VMware ESXi, and OpenVZ

Four platforms dominate the VPS and cloud hosting market, each with distinct architecture, performance characteristics, and use cases.

KVM: The Modern Cloud Standard

KVM has become the default hypervisor for the majority of public cloud and VPS providers over the past decade, and for good reason. By integrating directly into the Linux OS kernel, KVM gains access to the kernel’s mature memory management, process scheduling, device driver ecosystem, and security infrastructure without duplicating those capabilities in a separate hypervisor layer.

KVM uses hardware-assisted virtualisation extensions built into modern processors — Intel VT-x and AMD-V — to allow guest VMs to run most instructions directly on the physical CPU without hypervisor interception, reserving interception only for privileged instructions that could affect system stability or security. This approach, combined with the QEMU device emulation layer, delivers virtualisation overhead that is negligible for most workloads.

For VPS users, a KVM-based provider supports the full range of vCPU allocation models. CPU pinning for dedicated vCPU instances is natively supported through libvirt configuration, and KVM’s use of the Linux Completely Fair Scheduler for shared workloads provides well-tested, proportional CPU time distribution across shared vCPU VMs. KVM also fully supports burstable vCPU configurations implemented at the infrastructure layer by providers who build that model on top of KVM’s cgroup and scheduling controls.

Xen: Battle-Tested at Hyperscale

Xen predates KVM and built much of the modern cloud computing industry’s foundational infrastructure. Amazon Web Services ran on Xen for over a decade before beginning its transition to the custom Nitro hypervisor (itself KVM-derived). Rackspace, Linode (before its merger with Akamai), and many other early cloud providers standardised on Xen.

Xen’s architecture is distinctive: the hypervisor itself is a thin, privileged layer that boots before any operating system. Above it runs Dom0 — a privileged Linux instance that has direct hardware access and serves as the management layer for all guest VMs (called DomU in Xen terminology). This separation of the management domain from the hypervisor core gives Xen strong security isolation properties but also introduces a layer of complexity in management compared to KVM.

Xen supports two virtualisation modes: hardware virtual machine (HVM) mode uses processor virtualisation extensions for full hardware emulation, similar to KVM. Paravirtualisation (PV) mode requires guests to use a modified OS kernel that is aware of the hypervisor and communicates with it directly rather than going through hardware emulation — this historically offered better performance but is now less relevant as hardware virtualisation extensions have matured. Modern Xen deployments use HVM with PV drivers (PVHVM) as a practical compromise that delivers near-native performance without requiring a custom guest kernel.

VMware ESXi: Enterprise-Grade Resource Management

VMware ESXi is the hypervisor of choice for enterprise private cloud and managed hosting environments where predictable, SLA-guaranteed performance is a contractual requirement rather than a best-effort claim. While KVM and Xen dominate public cloud VPS hosting, ESXi dominates corporate data centres and the managed hosting tier above commodity VPS.

ESXi’s distinguishing feature is its CPU and memory resource management framework. Administrators can configure three levers per VM: CPU shares (a relative priority weight that determines scheduling precedence when the host is under load), CPU reservations (a guaranteed minimum allocation in MHz that the hypervisor must always deliver), and CPU limits (a hard ceiling on consumption even if spare capacity exists). This three-parameter model gives infrastructure teams precise control over how physical CPU cores are distributed across a mixed-criticality VM estate.

For users on managed ESXi hosting, this translates to the ability to purchase guaranteed resource allocations rather than best-effort shared access. An ESXi-hosted VM with a CPU reservation of 2GHz will always receive at least that compute allocation from the hypervisor, regardless of what other VMs on the host are doing — a behaviour that is equivalent to a dedicated vCPU guarantee even in a multi-tenant environment.

OpenVZ: Containers, Not Virtualisation

It is important to understand that OpenVZ is not a hypervisor in the traditional sense — it is an OS-level virtualisation platform that uses Linux containers rather than hardware virtualisation. All OpenVZ containers on a physical host share a single host OS kernel. There is no hypervisor intercepting hardware instructions; instead, the kernel’s namespace and cgroup features provide isolation between containers.

This architecture has significant implications. The advantages are efficiency — without a hypervisor layer, OpenVZ containers have minimal overhead, which is why OpenVZ-based providers can offer very cheap plans with high resource-to-price ratios. The limitations are equally significant: because all containers share the host kernel, guests cannot run a different Linux kernel version or a different operating system altogether. Windows VMs are impossible on OpenVZ. Kernel-level operations that require specific kernel features or versions may not work correctly. And the isolation between tenants is weaker than full virtualisation — a container escape vulnerability in the kernel affects all tenants on the host simultaneously.

For CPU allocation specifically, OpenVZ uses Linux cgroups to assign CPU shares to each container. This provides proportional CPU distribution under load but does not support the kind of hard CPU pinning that enables true dedicated vCPU allocations available on KVM or Xen. If a provider offers a “dedicated CPU” plan on OpenVZ, they are using a different mechanism than the hardware-level pinning available on full hypervisors — the guarantee is softer by architecture.

How Your Hypervisor Choice Affects Storage Performance

The hypervisor does not just manage CPU and RAM — it also mediates all storage I/O between virtual machines and the physical disks beneath them. This is where the choice of hypervisor, combined with the underlying storage hardware, has a significant impact on application performance.

Modern hypervisors like KVM support VirtIO — a paravirtualised I/O framework that allows guest VMs to communicate with storage and network devices through an efficient shared-memory interface rather than emulating legacy hardware. VirtIO storage drivers in the guest OS bypass much of the emulation overhead, allowing the full throughput of NVMe drives to reach virtual machines with minimal latency penalty.

On platforms that use older storage emulation (emulating a SATA controller, for example), the overhead is more significant — the hypervisor must translate every storage command through a hardware emulation layer. For providers whose infrastructure uses NVMe-backed storage, a KVM platform with VirtIO drivers is what allows those drive speeds to actually reach your workload rather than being bottlenecked at the virtualisation layer.

What the Hypervisor Means for VPS Isolation and Security

Beyond performance, the hypervisor is the primary security boundary between tenants in a multi-tenant cloud environment. A well-implemented Type 1 hypervisor ensures that one VM cannot read another VM’s memory, intercept another VM’s network traffic, or interfere with another VM’s storage — even if both VMs are running on the same physical host.

The security track record of the major hypervisors reflects decades of hardening. Both KVM and Xen have had vulnerabilities discovered and patched over their lifetimes — the Xen Security Advisory process is notably rigorous, with detailed public disclosure of every identified issue. VMware ESXi similarly maintains a security advisory programme, and ESXi’s small codebase (the hypervisor core itself is under 150MB) reduces the attack surface compared to a full general-purpose OS.

OpenVZ‘s shared kernel architecture means that the isolation boundary is the Linux kernel itself rather than a dedicated hypervisor. While Linux kernel security has improved dramatically, a kernel vulnerability that allows container escape affects all OpenVZ tenants on the host simultaneously — a different risk profile than a hypervisor escape vulnerability on KVM or Xen, where the blast radius is typically limited by the hypervisor’s own security boundary.

Choosing a Provider Based on Hypervisor

For most VPS buyers, the hypervisor question resolves simply: prefer a KVM-based provider unless you have a specific reason to choose otherwise. KVM is the modern standard, is well-documented, supports every mainstream operating system, and enables the full range of vCPU allocation models — from shared to burstable to dedicated. Nearly every current cloud provider of note has standardised on KVM or a KVM-derived platform.

Xen remains a solid choice with a proven track record, though fewer providers actively choose it for new deployments. If you are on a Xen-based platform, the performance and isolation characteristics are comparable to KVM for the vast majority of workloads.

VMware ESXi is the right choice when you are operating your own infrastructure or selecting a managed hosting provider where CPU and RAM reservations are contractually guaranteed. The tooling overhead and licensing costs make it impractical for commodity VPS, but for enterprise environments where resource guarantees are a requirement, ESXi’s management capabilities justify the investment.

OpenVZ is appropriate for budget use cases where the workload is Linux-only, kernel compatibility is not a concern, and cost efficiency is the primary decision factor. Development environments, lightweight web hosting, and workloads that do not require strong tenant isolation can run perfectly well on OpenVZ at meaningfully lower cost than full-virtualisation alternatives. Avoid it for production workloads that require a specific kernel version, Windows, or hard CPU isolation guarantees.

Summary

The hypervisor is the invisible foundation of every VPS — the software layer that partitions physical hardware into isolated virtual machines, mediates access to CPU cores, RAM, and NVMe storage, and enforces the isolation that keeps tenants from interfering with one another. KVM and Xen are the dominant open-source Type 1 hypervisors in public cloud hosting, both supporting full hardware virtualisation, CPU pinning for dedicated vCPU allocations, and strong tenant isolation. VMware ESXi leads enterprise and managed hosting with its granular resource reservation system. OpenVZ takes a fundamentally different container-based approach that trades isolation strength and flexibility for cost efficiency.

The hypervisor your provider uses determines whether dedicated vCPU pinning is genuinely possible, whether shared vCPU scheduling is fair and predictable, how efficiently fast NVMe storage reaches your workload, and how securely your virtual machine is isolated from its neighbours. It is worth knowing what is running beneath your server — and choosing a provider whose virtualisation platform matches the performance and isolation requirements of your workload.