Do You Know Who Your Neighbors Are?
It is 3:00 AM. Your pager is buzzing. Your Nagios dashboard shows your database server is down again. You SSH in, check /var/log/messages, and see nothing. You check dmesg. Nothing. The server isn't out of RAM, the load average is 0.5, yet MySQL refuses to start.
Welcome to the hell of oversold OpenVZ containers.
In the current hosting climate, everyone is racing to the bottom on price. Providers are cramming hundreds of containers onto a single physical node to maximize profit. While OpenVZ is a brilliant piece of engineering for density, it forces a trade-off that serious System Architects should strictly avoid for production workloads: Resource Isolation.
The Pros: Why OpenVZ is Popular
OpenVZ is not inherently bad. It is operating-system-level virtualization. There is no hypervisor overhead because every container (VE) runs on the host's single Linux kernel.
- Raw Performance: Since there is no hardware emulation, disk I/O and CPU execution are nearly native.
- Burstable RAM: You can allocate resources dynamically. If Container A isn't using its RAM, Container B can borrow it.
- Instant Provisioning: Creating a new VE takes seconds using standard templates like
centos-5-x86_64.
For a static HTML site or a low-traffic development sandbox, this is acceptable. But for a business-critical application?
The Cons: The "User Beancounters" Trap
Here is the war story. Last month, a client migrated a Magento e-commerce store to a generic budget VPS. The site was sluggish. They blamed the code. We looked deeper.
On OpenVZ, you are governed by /proc/user_beancounters. This file lists cryptic limits that, if hit, silently kill your processes. The most dangerous one is privvmpages.
cat /proc/user_beancounters
UID resource held maxheld barrier limit failcnt
101 privvmpages 45022 45022 50000 55000 432See that failcnt (failure count)? That means 432 times, an application tried to allocate memory and was told "No" by the kernel—even if the guest OS thought it had free RAM. This causes segmentation faults and corrupted data that standard monitoring tools inside the VPS cannot explain.
The "Noisy Neighbor" Effect
Because you share the kernel, you share the I/O scheduler. If your neighbor on the physical node decides to run a massive backup or a dd command, your disk latency spikes. In a shared kernel environment, one rogue container can drag down the entire node.
Pro Tip: Check your kernel version withuname -r. If you see "stab" or "vz" in the string, you are on OpenVZ. If you need to tunesysctl.confparameters likenet.ipv4.tcp_tw_reusefor high-traffic handling, you might find you don't have permission to change them because they are locked by the host node.
Why KVM is the Future (and the CoolVDS Standard)
With the recent inclusion of KVM (Kernel-based Virtual Machine) into the mainline Linux kernel and RHEL 5.4, the game has changed. Unlike OpenVZ, KVM provides hardware virtualization. Each VPS gets its own kernel.
Why does this matter for your business?
- True Isolation: If a neighbor crashes their kernel, your server keeps humming.
- Guaranteed Resources: RAM is reserved, not promised. No more
failcnt. - Custom Kernels: Need to compile a custom kernel with GRSecurity patches for enhanced security? On KVM, you can. On OpenVZ, you can't.
At CoolVDS, we realized that for the Norwegian market—where standards for stability and privacy are governed by strict regulations like the Personal Data Act (Personopplysningsloven)—shared kernels are a liability.
The Verdict: Stability Over Density
We are seeing more demand for low latency and high reliability, especially for connections routing through NIX (Norwegian Internet Exchange) in Oslo. You cannot achieve consistent sub-millisecond response times if you are fighting for CPU time slices on an overloaded OpenVZ node.
While we offer OpenVZ for budget-tier testing, our production standard is high-performance KVM backed by enterprise RAID-10 SAS storage (and we are currently testing the new Intel X25-M SSDs for even faster database performance).
Stop letting "failcnt" kill your uptime. If your application matters, give it its own kernel.
Ready for real isolation? Deploy a KVM instance on CoolVDS today and experience the stability of dedicated hardware without the price tag.