The Xen Hypervisor: Why Real Pros Don't Touch Oversold Containers

If I see one more hosting provider advertising "Burstable RAM" as a feature, I might just pull the plug on the rack myself. It is October 2010. We are building systems for high-concurrency web applications, not hosting IRC bots. Yet, half the "VPS" market in Europe is still pushing oversold OpenVZ containers where your neighbor's infinite loop becomes your latency spike.

At CoolVDS, we took a different path. We architected our Norwegian infrastructure strictly on the Xen Hypervisor. Why? Because when you are running a MySQL master with heavy writes or a Magento storefront handling Christmas traffic, "soft limits" on memory are a death sentence. You need rigid isolation.

This guide dives into the architecture of Xen, how to tune it for raw throughput, and why we enforce strict resource allocation at the kernel level.

The Architecture: Dom0, DomU, and the Ring Buffer

Unlike container-based virtualization, Xen creates a proper hypervisor layer. You have Domain0 (Dom0), the privileged domain that talks to the hardware, and DomainU (DomU), the unprivileged guests (your VPS).

The magic happens in how they communicate. They use shared memory ring buffers and event channels. This minimizes the overhead compared to full hardware emulation, but it guarantees that one DomU cannot easily steal CPU cycles from another if the scheduler is configured correctly.

Paravirtualization (PV) vs. HVM

In 2010, you have two choices. Hardware Virtual Machine (HVM) requires VT-x instructions on the CPU and runs unmodified operating systems (like Windows). But for Linux servers, Paravirtualization (PV) is superior.

In PV mode, the guest OS "knows" it is virtualized. It makes hypercalls directly to the Xen hypervisor instead of slow hardware calls. This results in near-native performance.

Pro Tip: Always use a Xen-aware kernel. In CentOS 5.5, the kernel-xen package is standard. Running a non-xen kernel in HVM mode for Linux is a waste of I/O cycles unless you have very specific module requirements.

War Story: The "OOM Killer" Nightmare

Last month, we migrated a client from a budget German host. They were running a standard LAMP stack on an OpenVZ container. Every night at 03:00, their MySQL service crashed. The logs showed nothing but a sudden termination.

The culprit? ubc_privvmpages. In container virtualization, providers often promise "1GB RAM + 2GB Burst." But the "Burst" is a lie; it's only available if the host node has free RAM. When the backup scripts ran on other containers at 03:00, the host RAM filled up, and the kernel invoked the Out of Memory (OOM) killer. It shot the process with the highest memory usage: MySQL.

On Xen (and CoolVDS), RAM is hard-reserved. If you pay for 1024MB, the hypervisor allocates 1024MB physical pages to your domain. No borrowing, no stealing, no crashing.

Technical Deep Dive: Configuring Xen for Performance

If you are managing your own clusters or curious how we tune our nodes at CoolVDS, it starts with the xend-config.sxp.

1. Pinning Dom0 Memory

The biggest mistake sysadmins make is letting Dom0 balloon. Dom0 needs dedicated RAM to handle I/O requests from guests. If Dom0 swaps, every VPS on the node lags.

Edit /boot/grub/menu.lst on the host node:

title CentOS (2.6.18-194.el5xen)
    root (hd0,0)
    kernel /xen.gz-2.6.18-194.el5 dom0_mem=512M
    module /vmlinuz-2.6.18-194.el5xen ro root=/dev/VolGroup00/LogVol00
    module /initrd-2.6.18-194.el5xen.img

Then, disable ballooning in /etc/xen/xend-config.sxp:

(dom0-min-mem 512)
(enable-dom0-ballooning no)

2. Scheduler Tuning

The credit scheduler is the default in Xen 3.x and 4.0. You can prioritize critical VMs by assigning weights. By default, all VMs have a weight of 256. If you have a critical database server, give it more credits.

# List current credits
xm sched-credit -d Domain-0

# Give the database VM double priority
xm sched-credit -d database_vm_01 -w 512

3. Disk I/O: The Move to SSD

Storage is the bottleneck of 2010. While 15k RPM SAS drives in RAID 10 are the industry standard, we are seeing the emergence of Enterprise SSDs (Solid State Drives). The random I/O performance on SSDs is roughly 50x higher than mechanical disks.

At CoolVDS, we have started deploying Intel X25-E configurations for database-heavy instances. If you are configuring a Xen guest configuration file (/etc/xen/vm01.cfg), ensure you are using the correct disk drivers:

name = "vm01"
memory = 1024
vcpus = 2
# Use tap:aio for file-backed or phy: for LVM backed (preferred for performance)
disk = [ 'phy:/dev/VolGroup00/vm01_disk,xvda,w', 'phy:/dev/VolGroup00/vm01_swap,xvdb,w' ]
vif = [ 'bridge=xenbr0' ]
bootloader = "/usr/bin/pygrub"

Using phy: mapping directly to an LVM volume on the host provides the lowest latency, bypassing the dom0 filesystem overhead.

The Norwegian Context: Latency and Law

Hosting in Norway isn't just about patriotism; it's about physics and privacy. The latency from Oslo to the rest of the Nordics via NIX (Norwegian Internet Exchange) is minimal—often under 5ms within the country.

Data Integrity under Personopplysningsloven

With the current Data Inspectorate (Datatilsynet) becoming stricter regarding the handling of personal data under the Personopplysningsloven (Personal Data Act), knowing exactly where your data physically resides is critical. Unlike US-based clouds where data might float between data centers, a Xen-based VPS in Oslo offers strict locality.

Why We Chose This Architecture

We didn't build CoolVDS to be the cheapest. We built it to be the one you deploy on when you can't afford a crash. By using Xen PV, LVM-backed storage, and strictly allocated RAM, we eliminate the "noisy neighbor" problem inherent in budget hosting.

It is simple math. Dedicated resources mean predictable performance. Burst resources mean gambling.

If your current host is swapping your MySQL buffer pool to disk because another customer launched a Perl script, it is time to move. Get a test instance up. Check the /proc/cpuinfo. Feel the difference of a system that respects your resources.