OpenVZ vs. Xen: The Truth About "Burstable" RAM and Overselling

If I had a krone for every time a client asked why their "512MB RAM" VPS crashed while running a simple Apache benchmark, I could retire to a cabin in Geilo. The shift from shared hosting to Virtual Private Servers (VPS) is the defining trend of 2009, but there is a dirty secret in the hosting industry that few providers talk about: Virtualization technology matters more than the specs on the sales page.

Most budget hosts in Europe are flooding the market with cheap OpenVZ containers. While OpenVZ is a brilliant piece of engineering, it is frequently abused to pack hundreds of customers onto a single physical server. As a System Administrator, you need to understand the difference between OS-level virtualization (OpenVZ) and Hardware Virtualization (Xen/KVM) before you deploy your next project.

The Architecture: Shared Kernel vs. Isolation

OpenVZ is not true hardware virtualization. It is a containerization technology based on the Linux kernel. Think of it as a chroot on steroids. All containers (VPSs) on the host node share the exact same kernel version.

The Pros:

• Efficiency: There is almost no overhead. The host doesn't need to emulate hardware.
• Scalability: You can change resources on the fly without rebooting (usually).
• Density: We can fit more instances on our high-speed SAS RAID arrays.

The Cons:

• Kernel Dependency: You cannot load your own kernel modules. Need a specific iptables module for a complex firewall? If the host node doesn't load it, you can't use it.
• The "Noisy Neighbor": If one user on the node triggers a kernel panic, everyone goes down.
• Swap Issues: OpenVZ handles memory management differently. It doesn't use a real swap partition inside the container; it uses "burstable" memory limits.

The Dreaded "User Beancounters"

In a Xen environment (which we standardize on for CoolVDS premium plans), RAM is RAM. If you have 512MB, it is allocated to you. In OpenVZ, resources are managed by a mechanism called user_beancounters (UBC). This is where inexperienced admins get burned.

If your MySQL process is killed mysteriously, don't just look at /var/log/messages. Check the UBC:

You will see a column called failcnt. If this number is greater than zero, you are hitting a barrier set by your host. The most common culprit is privvmpages. Many budget providers set this limit deceptively low, meaning your "512MB" VPS might actually prevent you from allocating memory well before you hit that limit physically.

Pro Tip for Database Tuning:
If you are running MySQL 5.0 on OpenVZ, be conservative with your innodb_buffer_pool_size. The overhead inside a container is counted against your privvmpages. A standard my.cnf optimized for a dedicated server will often trigger OOM (Out of Memory) kills in a container.

Performance: I/O Wait and Latency

In Norway, we are obsessed with latency. We have the NIX (Norwegian Internet Exchange) in Oslo ensuring local traffic stays local. However, network latency is irrelevant if your Disk I/O is saturated.

OpenVZ systems often suffer from I/O bottlenecks because the file system is shared. If one neighbor is compiling a kernel or running a heavy backup script, your read speeds will drop. This is why for I/O intensive applications—like a Magento e-commerce store or a heavy vBulletin forum—OpenVZ is a risk.

Comparison: OpenVZ vs. Xen

Data Privacy in 2009: Datatilsynet is Watching

Beyond technical specs, we must consider legal compliance. With the Datatilsynet (Data Inspectorate) enforcing the Personal Data Act strict interpretations, knowing exactly where your data resides is critical.

When you use budget OpenVZ hosting from international giants, your data might be moved between physical nodes across borders for load balancing without your knowledge. At CoolVDS, our infrastructure is strictly located in Norwegian data centers. We respect the physical sovereignty of your bits. Whether you are hosting patient data or just a corporate blog, keeping your servers under Norwegian jurisdiction (and power grids) is a layer of security you shouldn't ignore.

The Verdict

OpenVZ is not bad technology. It is excellent for development environments, DNS servers, or lightweight VPN tunnels. It is cost-effective and fast to provision.

However, for production workloads where uptime is money, relying on shared kernel resources is a gamble. If you need consistent disk I/O, the ability to tune your own kernel, or strict resource guarantees, you need hardware virtualization.

Don't let a noisy neighbor kill your uptime.
Deploy a true Xen-based VPS or a properly isolated OpenVZ container on CoolVDS today. We don't oversell, and our low latency to Oslo is verified.