Before the Xen project popped up on my radar three years ago, I’d never heard of paravirtualization. In this technique, an altered version of an operating system redirects privileged operations -- the bare metal code that restructures virtual memory and communicates with devices -- to a thin “hypervisor” layer, instead of sending them directly to the CPU. It’s far, far more efficient than intercepting and redirecting privileged operations at the CPU instruction level, as VMware, Microsoft Virtual Server, and other hardware emulation-based virtualization solutions must do.

Xen plants itself into a Linux source code tree as the equivalent of a new CPU architecture. When you compile Linux with Xen as the target architecture, you end up with a Linux that has paravirtualization baked in, rather than strapped on. At boot time, Xen’s small hypervisor loads before the Xen Linux host kernel does. From there, it just takes one simple command to launch Linux, BSD, NetWare, or one of a handful of other host OSes that have been modified to run as Xen guests.

I chuckled over Xen’s documented method for the ordinarily painful physical-to-virtual system migration: Use the “dd” command to copy the boot drive from another server to a local file, point Xen at that file, and boot the VM (virtual machine). Who needs consultants?

Despite being easy to install and run, the open source Xen is no lightweight, feature-deprived wannabe. Calling a Xen guest VM fast is not sufficiently descriptive. Xen’s a rush, and not just with regard to compute speed. My standard for virtualization performance is throughput, and Xen delivers. Storage and network I/O are speedy, and Xen is uncommonly flexible when it comes to storage. A guest VM can use dedicated drives or arrays, dedicated partitions on existing drives, or disk image files on one of the host’s mounted file systems.

Xen configuration parameters are stored in text files, and its management interface is a small set of simple command-line directives. Novell is working on a GUI management interface for Xen, but for a limited number of servers, it’s hard to beat Xen’s short, scriptable one-liners to launch, shut down, and query the status of and connect to the console of a virtual machine. Migrating a running VM from one physical server to another, a feature found in the likes of Virtual Iron and VMWare VirtualCenter, is also a one-liner, and Xen claims that its live migration is the fastest available. I can’t speak to that, but it takes but a fraction of a second and is barely noticeable during HTTP and SMTP (e-mail) sessions. With its low overhead, you could use Xen solely for maintaining high availability.

The XenSource Web site states that “Xen is, and always will be, open sourced.” Open source projects often impose trade-offs, relative to commercial software, that the community accepts to promote the open source cause. Xen doesn’t need a handicap to win. When Xen 3.0 ships in Q3 of 2006, both as an open source milestone and as a supported commercial enterprise solution from sponsor company XenSource, it will epitomize open source excellence in a way that makes it worth paying for.