OpenVZ VPS: How Container-Based Virtualisation Works and When It Makes Sense

OpenVZ occupies a specific and legitimate niche in the VPS hosting market: the budget tier. If you have ever rented a VPS for a few dollars a month and wondered how the provider makes the economics work, OpenVZ is usually part of the answer. By eliminating the overhead of a full hypervisor layer and sharing a single Linux OS kernel across all containers on a host, providers can pack far more tenants onto a single physical server than KVM or Xen would allow at comparable resource densities.

That density is genuinely valuable — if your workload fits the OpenVZ model. The problem is that many workloads do not, and the limitations only become apparent after you have deployed and hit a wall. This guide gives you the complete picture upfront: the architecture, the genuine strengths, the hard constraints, and the decision framework for choosing OpenVZ over full virtualisation alternatives.

How OpenVZ Works: Shared Kernel, Isolated Containers

Traditional hypervisor-based virtualisation — as implemented by KVM and Xen — creates fully independent virtual machines, each running its own operating system with its own OS kernel loaded into memory. The hypervisor sits beneath all of them, mediating hardware access and enforcing isolation at the hardware virtualisation layer.

OpenVZ works differently. There is no hypervisor and no hardware virtualisation. Instead, a single Linux kernel runs on the host server, and OpenVZ uses that kernel’s namespace and cgroup features to create isolated containers — what OpenVZ calls Virtual Private Servers or VEs (Virtual Environments). Each container has its own filesystem view, process table, network interfaces, user accounts, and resource limits, but all containers share the same underlying kernel.

From inside an OpenVZ container, the experience resembles a conventional Linux server: you have root access, can install packages, run services, and configure the system. But certain operations that require kernel-level access — loading kernel modules, modifying kernel parameters beyond what OpenVZ permits, or running a different kernel version — are not possible because the kernel is shared and its modification would affect every container on the host simultaneously.

Namespaces and cgroups: the isolation mechanism

The two Linux kernel features that make OpenVZ possible are namespaces and cgroups. Namespaces isolate what each container can see: a container has its own PID namespace (its process table is independent), its own network namespace (its own network interfaces and routing tables), its own mount namespace (its own filesystem view), and its own UTS namespace (its own hostname). From inside the container, it appears to be a standalone server; processes in other containers are invisible.

Cgroups (control groups) enforce resource limits: how much CPU time a container may consume, how much RAM it may allocate, and how much disk I/O bandwidth it may use. OpenVZ’s resource management layer — historically called UBC (User Beancounters) and now supplemented by standard cgroups — translates the resource allocations you purchase into kernel-enforced limits on your container.

This is the fundamental difference from a hypervisor-based isolation model: in KVM or Xen, the isolation boundary is the hardware virtualisation layer, enforced by the processor itself. In OpenVZ, the isolation boundary is the Linux kernel’s namespace and cgroup implementation — robust and well-tested, but a software boundary rather than a hardware one.

OpenVZ vs. Full Hypervisor Virtualisation

CPU Allocation on OpenVZ: How It Differs from Hypervisor Platforms

On KVM and Xen, the hypervisor scheduler manages CPU core access at the hardware virtualisation layer — and crucially, supports hard CPU pinning for dedicated vCPU allocations where a physical thread is exclusively reserved for one VM. On OpenVZ, there is no hypervisor scheduler. CPU allocation is managed entirely through Linux cgroups, using CPU shares and CPU quota mechanisms built into the host kernel.

CPU shares in cgroups are a proportional system: if all containers are competing for CPU simultaneously, the scheduler distributes time proportionally based on each container’s share weighting. A container with twice the shares of another gets roughly twice the CPU time during contention. But shares are a soft mechanism — they only matter when the CPU is actually contested. During idle periods, any container can use all available CPU without restriction, regardless of its share allocation.

CPU quotas add a hard ceiling: a container can be limited to using no more than a specified percentage of a CPU core regardless of host availability. This is how providers enforce the CPU limits on their OpenVZ plans — but it also means that even when the host has spare compute capacity, a quota-limited container cannot exceed its ceiling, unlike a burstable vCPU model on KVM that can consume spare capacity when available.

The consequence of this architecture is that OpenVZ cannot offer true dedicated vCPU allocations in the same sense as KVM or Xen. When a KVM provider pins a vCPU to a physical thread, the hardware enforces that exclusivity. When an OpenVZ provider offers “dedicated CPU,” they are using cgroup CPU pinning — binding a container’s processes to specific physical cores using the cpuset cgroup. This provides meaningful isolation but remains a software-enforced boundary, not a hardware one. Under host-level load spikes or kernel scheduling anomalies, the isolation guarantees are softer than on a full hypervisor.

Memory on OpenVZ: Guarantees and Overcommit

RAM allocation on OpenVZ has historically been one of its most confusing aspects. OpenVZ uses a dual-limit system: a guaranteed memory limit (the amount always available to the container) and a burst limit (the maximum it can consume if host memory is available). In practice, many budget OpenVZ providers set the guaranteed limit significantly below the advertised RAM figure and rely on the burst limit — meaning your container may see its available memory shrink when the host is under memory pressure from other containers.

Modern OpenVZ 7, based on CentOS 7 / RHEL 7, moves toward standard cgroup memory limits that are cleaner and easier to understand — a hard memory limit that the container cannot exceed. But the overcommit behaviour of the underlying host still affects containers: if the sum of all container memory limits exceeds host physical RAM, the host kernel may start swapping or invoking the OOM (Out of Memory) killer against container processes when total demand exceeds physical capacity.

For workloads with predictable, modest memory footprints — a small web server, a development environment, a lightweight database — this is rarely a problem in practice. For workloads that genuinely need guaranteed RAM availability — production databases, in-memory caches, or applications with large working sets — a KVM-based provider with reserved memory allocation is more appropriate than relying on OpenVZ’s softer memory model.

Storage on OpenVZ: Performance and Architecture

Storage access in OpenVZ containers goes through the host OS kernel‘s filesystem layer directly — there is no hypervisor storage virtualisation layer and no VirtIO or PVSCSI translation as on KVM or VMware ESXi. This means the raw storage access path has very low overhead — container I/O reaches the physical storage with minimal additional latency introduced by the virtualisation layer itself.

Whether that translates into good storage performance depends entirely on what the provider has deployed at the hardware level. An OpenVZ host with NVMe drives delivers fast I/O to all containers — the low-overhead storage path means NVMe’s speed advantage is fully preserved. An OpenVZ host with spinning HDDs delivers poor I/O to all containers with no virtualisation overhead to blame — the hardware is simply the bottleneck.

The storage isolation story is more nuanced, however. Because all containers share the same host kernel I/O scheduler, a container generating heavy disk I/O can affect the storage performance of other containers on the same host more directly than on a hypervisor-based platform where each VM’s I/O is mediated separately. Providers mitigate this through cgroup I/O throttling, but the isolation is again softer than the hardware-level separation that KVM with VirtIO provides.

The Hard Constraints: What OpenVZ Cannot Do

The shared kernel architecture of OpenVZ creates several hard constraints that no amount of provider configuration can work around. These are not limitations of any specific implementation — they are inherent to the OS-level virtualisation model.

Where OpenVZ Is the Right Choice

The constraints above are real, but they do not make OpenVZ a bad choice for the workloads it is genuinely suited to. The near-zero overhead of container virtualisation, combined with aggressive resource packing on the host, allows OpenVZ providers to offer VPS plans at price points that full hypervisor platforms cannot match. For the right workloads, that cost efficiency is the dominant factor.

OpenVZ 7 and the Move Toward Virtuozzo

The OpenVZ project has evolved significantly since its origins in the early 2000s. The original OpenVZ was based on a heavily patched custom Linux kernel maintained separately from the mainline kernel — a significant maintenance burden that led to the project lagging behind upstream kernel features and security patches.

OpenVZ 7, released in 2016 and based on RHEL/CentOS 7, moved the platform toward upstream kernel technologies — using mainline Linux namespace and cgroup features rather than the custom patches of earlier versions. This alignment with the mainline kernel means OpenVZ 7 hosts benefit from standard Linux kernel security updates rather than depending on a fork-specific patch cycle.

Virtuozzo, the commercial product built on OpenVZ technology, goes further — adding management tooling, high availability features, and a storage layer (Virtuozzo Storage, a distributed software-defined storage system that can be backed by NVMe drives) oriented toward providers running OpenVZ at scale. For buyers, the practical distinction between OpenVZ and Virtuozzo is mainly relevant at the provider infrastructure level — container behaviour from the tenant’s perspective is similar on both platforms.

Diagnosing an OpenVZ Environment

If you are unsure whether your VPS is running on OpenVZ or a full hypervisor, several quick checks will confirm it.

• Detection command: Run systemd-detect-virt — it returns openvz on OpenVZ containers. Alternatively, check cat /proc/1/environ | tr '\0' '\n' | grep container or look for /proc/vz — a directory present only on OpenVZ systems.
• Kernel version: Run uname -r — inside an OpenVZ container, this returns the host kernel version, not a guest-specific kernel. If the kernel version matches a standard CentOS/RHEL kernel rather than a distribution-specific one, it is likely OpenVZ.
• Resource counters: cat /proc/user_beancounters is an OpenVZ-specific file. If it exists and returns data, you are on OpenVZ or Virtuozzo.
• Missing hardware: lscpu inside an OpenVZ container may show the full host CPU topology rather than a virtualised view — unlike KVM or Xen, which present a virtualised CPU to the guest.

OpenVZ vs. Modern Docker and LXC

It is worth noting that OpenVZ predates and inspired many of the container technologies now common in modern infrastructure. Linux Containers (LXC), Docker, and Podman all use the same underlying kernel primitives — namespaces and cgroups — that OpenVZ pioneered in its early patched kernel versions.

The key difference is context: Docker and LXC run as application containerisation tools on top of a host operating system managed by the user, typically on a KVM or bare-metal server the operator controls. OpenVZ is used by hosting providers to create tenant-isolated VPS environments on shared infrastructure. The underlying technology is similar; the deployment model and isolation expectations differ significantly.

For buyers who need to run Docker containers on their VPS — a common modern workload — OpenVZ is the wrong platform. Docker running inside an OpenVZ container creates nested namespace management conflicts that produce unreliable behaviour. A KVM-based VPS, which provides a fully isolated OS kernel that Docker can manage entirely, is the correct choice for containerised application deployments.

Summary

OpenVZ is a container-based virtualisation platform that creates isolated Linux environments on a shared host OS kernel, without the hardware virtualisation layer of a true hypervisor. Its near-zero overhead enables the resource density that makes budget VPS pricing possible, and for Linux-only workloads with modest kernel requirements — development environments, simple web hosting, lightweight services, and experimental infrastructure — it is a cost-effective and entirely legitimate choice.

Its hard constraints are equally real: no custom kernel, no Windows, no Docker, softer CPU isolation than the hardware pinning available on KVM or Xen, and a security isolation model that depends on kernel-level namespaces rather than a hypervisor boundary. For production workloads requiring true dedicated vCPU guarantees, guaranteed RAM reservations, containerised application deployments, or non-Linux operating systems, a full hypervisor platform — KVM, Xen, or VMware ESXi — is the appropriate foundation. Pairing the right virtualisation platform with NVMe-backed storage, adequate CPU core allocation, and reserved RAM is what separates a well-chosen infrastructure stack from one that surprises you at the worst possible moment.