Proxmox vs. traditional VPS — what the difference means for your hosting

When you buy a VPS, the marketing usually tells you the same things: vCPUs, RAM, SSD storage, bandwidth. What it doesn't always tell you is how those resources are allocated, what happens when the physical host is under load, and whether the isolation between your VPS and the one next to it is meaningful.

This depends almost entirely on which hypervisor the provider is running. The difference between OpenVZ, Xen, and KVM on Proxmox matters a great deal for certain workloads.

OpenVZ: containers, not virtualisation

OpenVZ is a container-based system, not a hypervisor. Multiple OpenVZ containers share the same Linux kernel on the host. This is efficient — containers start fast, overhead is low, and a host can fit more containers than VMs — but it comes with significant limitations.

The kernel is shared. You cannot run a different kernel version in your OpenVZ container than the host is running. You cannot load kernel modules. If you need something that requires a custom kernel — WireGuard on an old kernel, certain filesystem features, Docker's full feature set — you cannot have it.

Resources can be overcommitted. OpenVZ's resource limits are flexible in ways that can work against you. A provider can promise you 4GB RAM across 20 containers on a host with 64GB RAM. If all 20 containers try to use their full allocation simultaneously, the host pages to disk. This is the "noisy neighbour" problem in its most acute form.

Isolation is weaker. While OpenVZ does provide isolation between containers, they share the kernel's memory and process namespaces at a lower level than full virtualisation. Security vulnerabilities in the kernel can be exploited from within a container.

Xen: full virtualisation with a hypervisor

Xen is a true hypervisor. Each VM runs its own kernel. Xen runs below the operating system and manages CPU, memory, and I/O scheduling across all VMs. This is what AWS uses for older EC2 instance types (now transitioning to Nitro, which is KVM-derived).

Xen provides proper isolation — each VM has its own kernel and memory. The trade-off is that Xen's I/O model (historically via the Dom0 driver domain) could create I/O contention, and Xen's toolstack has historically been more complex to manage.

For end users, Xen VPS hosting is meaningfully better than OpenVZ in terms of isolation and resource guarantees. But not all Xen deployments are equal — providers can still overcommit memory and CPU on Xen hosts.

KVM on Proxmox: what we run

KVM (Kernel-based Virtual Machine) is built into the Linux kernel. Every KVM VM is a full virtual machine with its own virtualised CPU, RAM, and I/O. KVM uses QEMU for device emulation and hardware acceleration (Intel VT-x / AMD-V) for near-native CPU performance.

Proxmox VE is the management platform we use to run KVM. It handles VM provisioning, migration, backup, storage management, and high-availability clustering. But the important thing from your perspective as a customer is what KVM on Proxmox means for your VPS:

Your own kernel. Run any Linux kernel. Load any kernel module. Run Docker with full cgroup support, WireGuard, custom filesystem drivers — anything that requires a specific kernel version or module.

Dedicated resource allocation. We allocate RAM to your VM. That RAM is not available to other VMs on the host. CPU cores are allocated with scheduler guarantees. Storage I/O is on NVMe where available, with IOPS limits per VM to prevent one customer from saturating the disk.

Full root access. You have a VM, not a container. You can install any software, configure the kernel, modify network settings, run nested virtualisation (where hardware supports it).

Live migration. Proxmox supports live migration of running VMs between physical hosts without downtime. When we need to do maintenance on a physical host, your VPS can be migrated to another host while it's running. This is a significant operational advantage over providers who take VMs offline for host maintenance.

When the difference matters

For most web hosting workloads — a PHP application, a Node.js service, a database — the difference between a well-configured OpenVZ container and a KVM VM is not visible day-to-day. Both serve requests, both have reasonable isolation, both work.

The difference matters when:

You need Docker. Full Docker support (including Docker's own namespace features) requires proper kernel isolation. Docker in an OpenVZ container is limited and fragile.

You need a custom kernel or modules. Security software, network utilities, certain monitoring tools all require kernel-level access.

Your workload is I/O intensive. KVM's I/O allocation model is more predictable under load than OpenVZ's shared-kernel approach.

You care about security isolation. Kernel vulnerabilities in OpenVZ affect all containers on the host. In KVM, a kernel vulnerability in your VM's kernel doesn't give an attacker access to the hypervisor or other VMs (though hypervisor escapes exist in theory, they're much rarer and harder than container escapes).

You need the resources you paid for, consistently. Providers running KVM with proper resource allocation can't silently overcommit your RAM. Your 4GB is 4GB, not 4GB when nobody else wants it.

FXRM VPS hosting runs KVM on Proxmox. Full root access, your own kernel, NVMe storage where available, UK data centre. See VPS plans →