Container Wars 2013: LXC vs. OpenVZ for High-Load Norwegian Infrastructure

I have seen servers melt. Not literally, but the silicon might as well have been slag. Last week, a client running a high-traffic Magento cluster on a budget "cloud" provider in Oslo hit a wall. Their site didn't go down; it just slowed to a crawl. The culprit? Failcounts in /proc/user_beancounters.

If you are renting a cheap VPS in 2013, you are likely sitting inside an OpenVZ container, fighting for CPU cycles with fifty other noisy neighbors. It is the dirty secret of the hosting industry. Overselling is the business model. But for those of us managing serious infrastructure—whether it's for the oil sector in Stavanger or media streaming in Oslo—we need predictability. The buzz right now is all about lightweight containers. Docker is making waves with its 0.4 release, wrapping LXC in something usable, but the battle for production dominance is currently fought between the veteran OpenVZ and the mainline contender LXC (Linux Containers).

The Problem: The "Noisy Neighbor" and Kernel Panics

Here is the reality of shared kernel virtualization. Unlike KVM (Kernel-based Virtual Machine), where you get your own kernel and dedicated memory space, containers share the host's kernel. This is great for density. It is terrible for isolation.

I recently audited a setup where a single compromised WordPress install on an OpenVZ node caused a kernel panic that took down 40 other clients. That is unacceptable. If you are handling sensitive data subject to Datatilsynet regulations here in Norway, cross-contamination is a nightmare scenario.

OpenVZ: The Legacy Giant

OpenVZ has been the standard for years. It relies on a patched RHEL/CentOS 6 kernel (2.6.32). It is stable, but it is old. The resource management is done via "beancounters." If you have ever seen a `Cannot allocate memory` error despite having 2GB free, you have hit a barrier limit, not a RAM limit.

A typical OpenVZ limit check looks like this:

cat /proc/user_beancounters 
# Look at the failcnt column. If it's not zero, your host is choking you.
Uid  resource           held    maxheld    barrier      limit    failcnt
101  kmemsize        2641046    2940125   11055923   11377049          0
     lockedpages           0          0        256        256          0
     privvmpages       68102      72456     150000     200200         42

See that `42` in `privvmpages`? That is 42 times your application crashed or stalled because the provider set an artificial limit on memory allocation, even if the physical RAM was available. This is why "burst" RAM marketing is often nonsense.

LXC: The Mainline Future

LXC uses kernel features (cgroups and namespaces) directly in the upstream Linux kernel. No heavy patches required. It is available right now in Ubuntu 12.04 LTS. It feels more like a real Linux system and less like a cage.

To create a base container in Ubuntu, we aren't using proprietary templates. We use the tools standard to the OS:

sudo apt-get install lxc
sudo lxc-create -t ubuntu -n heavy-worker-01
sudo lxc-start -n heavy-worker-01

The configuration is cleaner. Instead of obscure bean counters, we use cgroups to limit resources. This allows for much more granular control over I/O, which is critical if you are pushing data across the NIX (Norwegian Internet Exchange).

Here is how you strictly limit memory and CPU in /var/lib/lxc/heavy-worker-01/config:

lxc.cgroup.memory.limit_in_bytes = 2G
lxc.cgroup.memory.memsw.limit_in_bytes = 3G
lxc.cgroup.cpuset.cpus = 0,1

Orchestration in 2013: Shell vs. Puppet

We don't have magic automated clusters yet. If you are managing 50 containers, you are likely writing Bash loops or using Puppet. The "orchestration" right now is essentially configuration management.

If you are deploying a web cluster, you might script the creation of containers. A simple robust approach I use involves a loop to spawn workers and inject SSH keys:

#!/bin/bash
# Simple LXC Provisioner for Web Nodes

for i in {1..5}
do
  NAME="web-node-$i"
  echo "Deploying $NAME..."
  lxc-create -t ubuntu -n $NAME
  
  # Inject authorized_keys for Ansible/Puppet management
  mkdir -p /var/lib/lxc/$NAME/rootfs/root/.ssh
  cat ~/.ssh/id_rsa.pub >> /var/lib/lxc/$NAME/rootfs/root/.ssh/authorized_keys
  chmod 700 /var/lib/lxc/$NAME/rootfs/root/.ssh
  
  lxc-start -n $NAME -d
done

Once they are up, you use Puppet or Chef to handle the insides. This works, but networking is a pain. You often end up messing with `iptables` NAT rules or bridging interfaces manually (`br0`) to get these containers on the public network.

The CoolVDS Factor: Why KVM is still King

While containers offer speed, they lack the hard isolation of hardware virtualization. In a container, if the host kernel chokes on I/O wait, everyone suffers. This is called the "Noisy Neighbor" effect.

Pro Tip: Check your "Steal Time" inside your VM. Run `top` and look for `%st`. If it is above 0.0, your provider is overselling the CPU. Move your data immediately.

At CoolVDS, we took a different path. We don't oversell. We use KVM (Kernel-based Virtual Machine). When you buy a VPS from us, you get a dedicated slice of the CPU scheduler and reserved RAM. The kernel is yours. You can load custom modules, tune `sysctl.conf` for high-latency satellite connections (common in Northern Norway), or even run Docker/LXC inside your CoolVDS instance for your own development.

Performance Benchmark: Disk I/O

I ran a quick `dd` test comparing a standard OpenVZ container from a competitor versus a KVM instance on CoolVDS. The target: writing 1GB of zeros.

The difference is the storage backend. We are rolling out SSD caching and pure SSD arrays. OpenVZ providers often dump hundreds of containers on a single SATA RAID array. When one client runs a backup, your database latency spikes to 500ms.

Conclusion: Choose Isolation

If you are experimenting, play with LXC on your laptop or try the new Docker beta. But for production infrastructure hosting mission-critical Norwegian business data, you cannot risk shared kernel exploits or resource starvation.

You need the raw power of KVM backed by low-latency storage. You need to know that 100% CPU means your CPU, not a time-slice shared with a Minecraft server next door.

Stop fighting the `failcnt`. Deploy a true KVM instance on CoolVDS today and get root access in under 55 seconds.