The "Unlimited" Resource Myth
It’s a familiar story in the hosting forums. You buy a VPS for 50 NOK a month. It promises 2GB of RAM and "unlimited" CPU. For the first week, your WordPress blog flies. Then, Monday morning hits. Your latency to NIX (Norwegian Internet Exchange) spikes from 2ms to 200ms. Your MySQL service crashes with an obscure memory error.
Welcome to the reality of oversold OpenVZ containers.
In the current hosting landscape of 2011, virtualization usually falls into two camps: Operating System-level virtualization (OpenVZ, Virtuozzo) and Hardware-level virtualization (Xen, KVM, VMware). Understanding the difference is not just academic—it determines whether your e-commerce site survives the Christmas rush.
Under the Hood: How OpenVZ Works
OpenVZ is not true virtualization; it's containerization. It creates multiple isolated secure containers (VEs) on a single physical server. Crucially, every container shares the same Linux kernel.
This architecture is brilliant for efficiency. There is almost no overhead. The host doesn't need to emulate a BIOS or PCI bus. File I/O is native. This is why providers love it—they can cram hundreds of containers onto one server.
Pro Tip: Checking your limits
If you are on an OpenVZ system, you can see your resource limits by reading the "beancounters" file. Run this command:cat /proc/user_beancountersLook at thefailcntcolumn. If it's anything other than 0, your provider is hitting you with limits you might not even know existed.
The Problem: The "Noisy Neighbor" & Kernel Panics
The shared kernel is OpenVZ's Achilles' heel. If one user on the node discovers a kernel exploit or triggers a kernel panic, the entire physical server goes down. Your uptime is effectively held hostage by the worst sysadmin on the same machine.
Furthermore, resource isolation in OpenVZ is soft. While providers set limits, the nature of the shared scheduler means that if Neighbor A decides to compile a custom kernel (which they can't even run, ironically) or run a heavy tar backup script, your disk I/O waits in line. We call this "CPU Steal," and on oversold nodes, it’s a performance killer.
Comparison: OpenVZ vs. Xen/KVM
| Feature | OpenVZ | Xen / KVM |
|---|---|---|
| Kernel | Shared (Host Kernel) | Isolated (Own Kernel) |
| Overhead | Very Low (1-2%) | Moderate (Hypervisor overhead) |
| Custom Modules | No (Cannot load iptables modules easily) | Yes (Full control) |
| Swap | Fake "Burst" RAM | Real Swap Partition |
| Stability | Dependent on neighbors | High Isolation |
Why "Burst RAM" is a Trap
OpenVZ marketing often highlights "Burst RAM." You might see a plan offering "512MB Guaranteed / 1GB Burst." This sounds generous, but technically, Burst RAM is unstable. It is memory you can use only if no one else needs it. When the host gets busy, the kernel ruthlessly kills processes using burst memory to reclaim stability. Usually, mysqld is the first victim.
For a static HTML site, this is fine. For a Magento store or a busy forum running vBulletin, it is suicide.
Data Sovereignty and The Norwegian Context
Beyond performance, we must consider legal risks. With the EU Data Protection Directive and Norway’s strict Personopplysningsloven, you are responsible for your customer's data. In a shared kernel environment (OpenVZ), escaping the container to access neighbor data is theoretically easier than breaking out of a hardware hypervisor like Xen.
Furthermore, many cheap VPS providers host in the US. Under the Patriot Act, your data is subject to foreign inspection. Hosting locally in Oslo or within the EEA isn't just about latency—it's about compliance with Datatilsynet's guidelines.
The CoolVDS Approach: Performance Without Compromise
At CoolVDS, we recognize that OpenVZ has its place—mostly for testing or non-critical development environments. However, for production workloads, we standardize on KVM (Kernel-based Virtual Machine).
With our KVM instances backed by enterprise-grade SSDs (a massive upgrade over the standard SATA 7.2k drives used by budget hosts), you get:
- Full Kernel Control: Need to tune
sysctl.conffor high-concurrency TCP? Go ahead. - Hard Resource Limits: Your RAM is yours. No one can steal it.
- Low Latency Storage: Our SSD arrays ensure your database queries don't hang waiting for the disk head to spin.
Don't let a 50 NOK saving cost you thousands in lost revenue. If your project demands stability, stop sharing your kernel with strangers.
Ready to upgrade? Deploy a KVM instance in our Oslo datacenter today and experience the difference of dedicated resources.