VPS Architecture Explained: Hypervisors, CPU Shares, and I/O Limits

A VPS is not a tiny physical server — it is a slice of a larger machine carved out by a hypervisor, and the way that slice is scheduled determines your real-world performance more than the sticker specs do. Two “4 vCPU / 8 GB” plans can differ by 30% in throughput depending on the hypervisor, CPU scheduler, and I/O limiting in place. This guide explains the architecture layers between your processes and the bare metal, and how to inspect each one from inside your instance.

Architecture also explains pricing. Providers charging more for “dedicated vCPU” are selling scheduler isolation, and it is worth real money for latency-sensitive workloads — compare VPS providers on our comparison table to see which ones disclose their virtualization and oversubscription policies.

Type 1 vs Type 2 Hypervisors

Type 1 hypervisors (KVM, Xen, VMware ESXi, Proxmox VE) run directly on hardware and give each VM near-native performance. Type 2 hypervisors (VirtualBox, QEMU without KVM acceleration) sit on top of a host OS and add a layer of overhead — you rarely see these in production VPS hosting. Container-based “VPS” products (LXC, OpenVZ) are not VMs at all: they share the host kernel, which is why they are cheaper and why some kernel tweaks silently no-op on them.

Technology	Isolation	Overhead	Typical use
KVM / Xen	Full VM, own kernel	~2–5%	mainstream VPS
VMware ESXi	Full VM	~2–5%	enterprise clouds
LXC / OpenVZ	Shared host kernel	~0–1%	budget containers
Type 2 (QEMU)	Full VM	5–20%	dev/test only

How CPU Shares and Steal Time Work

A “vCPU” is not a core — it is a right to use a core for some fraction of the host’s scheduling window. When the host is oversubscribed, your VM waits for its turn, and that wait shows up as steal time (%st). Steal above 5% sustained means your benchmark numbers are already lying to you about the machine’s capability.

top        # watch %st in the CPU summary line
mpstat -P ALL 2   # per-vCPU steal
vmstat 2          # 'st' column

Memory Allocation: Guarantees, Burst, and Ballooning

Most KVM providers allocate RAM as a hard guarantee, but some use balloon drivers that reclaim idle pages from your VM when neighbors need them — which shows up as sudden swapping inside your instance for no local reason. Check whether your provider documents ballooning; if your free -h numbers shrink without any process growth, you are on a ballooned host. Also verify whether the plan’s RAM is “guaranteed” or “burstable”: burstable plans trade stable performance for a lower price.

Disk and Network I/O Limits: Burst vs Sustained

Hypervisors throttle I/O with token buckets: a plan may advertise “1 Gbps” and “high IOPS” while the sustained rate is a fraction of the burst. This is why fio and iperf3 runs longer than 60 seconds reveal what short benchmarks hide. If sustained throughput drops to a flat ceiling after a burst window, you have hit the provider’s limit, not a configuration problem. The same burst-vs-sustained split applies to CPU: a plan with “turbo” or “boost” vCPUs can look fast in a 30-second sysbench run and throttle during a long build, so always run CPU benchmarks for at least two minutes and record the final third of the results.

Disk contention is the least visible limit of all. On a shared storage backend, your neighbor’s backup job can double your iowait even when your own I/O is idle. If iostat -x 2 shows high %util or await spikes on a quiet server, storage is oversubscribed — a provider-level issue that only migrating to a host with dedicated NVMe (or a provider that publishes storage ratios) will fix.

Inspecting Your Slice From the Inside

These commands identify the virtualization platform and current allocation without any provider API access:

lscpu | grep -E 'Hypervisor|Model name|CPU\(s\)'
systemd-detect-virt        # kvm, xen, lxc, ...
nproc && cat /proc/cpuinfo | grep -c processor
free -h                    # watch for ballooning over time
lsblk -d -o NAME,ROTA      # 0 = SSD, 1 = spinning disk

What This Means When You Buy

Match the allocation model to the workload. A cron-driven batch job tolerates oversubscription; a low-latency API or game server does not — pay for dedicated vCPUs and guaranteed RAM there. Before committing, read whether the provider publishes virtualization type, oversubscription ratios, and sustained I/O caps; if the numbers are not public, treat the plan as burstable by default and see the full specs and pricing on the main site for a side-by-side view.

Understanding the hypervisor layer turns VPS performance from guesswork into accounting: check steal time, watch for ballooning, and test sustained I/O. Do that before you tune a single kernel parameter, and you will know whether the bottleneck is your config or the slice you were sold.