The Lie of "Dedicated" Resources in 2012

If I see one more hosting provider selling an OpenVZ container as a "Virtual Dedicated Server," I'm going to pull the CAT5 cables out of their rack myself. Let’s be honest: if you are running a high-traffic MySQL cluster or a Java application stack on a container-based virtualization platform, you are asking for trouble. You are sharing a kernel with twenty other customers, and when "Customer A" decides to run a fork bomb or a poorly optimized PHP script, your latency spikes. In the world of systems administration, latency is the enemy of stability.

We are seeing a massive shift right now. With Red Hat Enterprise Linux 6 pushing KVM (Kernel-based Virtual Machine) as the default hypervisor, the days of Xen PV dominance and OpenVZ overselling are numbered. For those of us managing infrastructure targeting the Nordic market, where the Norwegian Internet Exchange (NIX) in Oslo sets the standard for speed, we need true isolation. We need KVM.

Why KVM is the "Iron" You Need

Unlike containerization, KVM turns the Linux kernel into a hypervisor. This means your VPS has its own kernel, its own memory management, and most importantly, true isolation. You aren't just getting a folder on a host OS; you are getting a virtual motherboard.

This matters for the "Battle-Hardened" sysadmin for three reasons:

1. No Steal Time: On OpenVZ, check your top command. See that st (steal) percentage? That’s your CPU cycles being stolen by another customer. On a properly configured KVM node, that should be near zero.
2. Custom Kernels: Need to enable specific modules for IPTables or tune the TCP stack for high concurrency? On KVM, you can compile and install your own kernel. On containers, you take what the host gives you.
3. SELinux Support: Security is not optional. Running SELinux inside a container is often a nightmare or impossible. On KVM, it works natively.

Pro Tip: Always verify your CPU supports hardware virtualization extensions before deploying a KVM host. If you are building your own lab, check the flags.

# grep -E 'svm|vmx' /proc/cpuinfo
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority

Tuning KVM for Performance: The VirtIO Secret

Out of the box, KVM can be slow if you emulate legacy hardware (like an IDE disk controller or a Realtek network card). The secret to near-native performance is VirtIO. These are paravirtualized drivers that let the guest OS know it's running virtually, allowing it to talk directly to the hypervisor with minimal overhead.

Here is how we configure our XML definitions at CoolVDS to ensure the disk I/O doesn't crawl. If you are managing your own libvirt setups, ensure your disk driver type is set strictly to virtio.

<disk type='file' device='disk'>
  <driver name='qemu' type='qcow2' cache='none'/>
  <source file='/var/lib/libvirt/images/production-db.qcow2'/>
  <target dev='vda' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>

Notice cache='none'. This bypasses the host's page cache, allowing the guest to manage its own I/O scheduling. Combine this with the deadline or noop scheduler inside your Linux guest for maximum throughput on SSDs.

# Inside the Guest VM (CentOS 6 / Debian 6)
# Edit /boot/grub/grub.conf or menu.lst
kernel /vmlinuz-2.6.32-279.el6.x86_64 ro root=/dev/vda1 elevator=noop

The Storage Bottleneck: HDD vs. SSD

In 2012, the biggest bottleneck is still the spinning rust. Hard drives (HDDs) cannot keep up with the random I/O of a busy web server. At CoolVDS, we made the decision to move our primary tiers to Pure SSD (Solid State Drive) RAID-10 arrays. This isn't just about boot times; it's about database transaction locks.

When running benchmarks using `fio` or `dd`, the difference is staggering. An average 7200RPM SATA drive might give you 80-100 IOPS. An Enterprise SSD array can push thousands.

# A simple write test (Don't run this on a production DB server!)
dd if=/dev/zero of=testfile bs=1G count=1 oflag=direct

# Standard VPS Result:
# 1073741824 bytes (1.1 GB) copied, 15.23 s, 70.5 MB/s

# CoolVDS SSD Result:
# 1073741824 bytes (1.1 GB) copied, 3.1 s, 346 MB/s

The "Norwegian Advantage": Datatilsynet & Latency

Tech is only half the battle. The legal landscape regarding data privacy is tightening. The Norwegian Data Inspectorate (Datatilsynet) is very clear about the responsibilities of data handlers under the Personal Data Act. With the uncertainty surrounding the US Safe Harbor framework, many CTOs are realizing that keeping data physically located in Norway is the safest bet for compliance.

Furthermore, physics is undefeated. If your customers are in Oslo, Bergen, or Trondheim, hosting in a datacenter in Germany or the US adds 30ms to 100ms of latency. By peering directly at NIX (Norwegian Internet Exchange), CoolVDS ensures that your packets take the shortest possible path. In e-commerce, 100ms can be the difference between a sale and an abandoned cart.

Comparison: Virtualization Technologies in 2012

Final Thoughts: Don't Compromise

We are building the future of the web, and that future requires robust foundations. You wouldn't build a skyscraper on a swamp, so don't build your application on shared kernels and spinning disks. Whether you are deploying the latest Nginx stack or a massive PostgreSQL database, you need the isolation of KVM and the speed of SSDs.

Stop fighting with noisy neighbors. If you need low latency to Oslo and rock-solid I/O performance, it's time to upgrade.

Deploy a KVM SSD instance on CoolVDS today and see what your top command should actually look like.