The recent launch of Suse Linux Enterprise Server (SLES) 10 put Xen into the commercial mainstream. If you haven’t come across it, Xen is a fledgling open-source server virtualisation technology. SLES 10 is the first commercially supported operating system to include Xen, but it won’t be the last.

In the beginning, Xen was available as source code suitable for Linux experts to add to their systems. Since March, version 3 of Xen has also been included in Red Hat Fedora Core (FC) 5, which is distributed free of charge, but without Red Hat support options. Red Hat will add Xen to its commercially supported operating system, Red Hat Enterprise Linux (RHEL) 5, which is expected in December.

So when Novell shipped SLES 10 in July, it pipped Red Hat to the post in terms of delivering a commercially supported Xen option. This has caused something of a mud fight between the two protagonists. Red Hat’s chief technology officer (CTO), Brian Stevens, argues that Xen is not yet capable of hosting enterprise applications. But Novell CTO Jeff Jaffe says his firm has done a lot of testing and thinks Xen is ready for enterprise users.

I’ve used Xen under FC5 and SLES 10, and both these men are partly right. Xen is not yet ready for enterprise applications, but it is ready for firms to begin evaluating the technology.

Firms considering virtualisation would be foolish not to look at Xen now to better understand the differences between Xen and the other virtualisation options. Some might even use Xen for applications that are not mission-critical – why not spin up a secondary DNS server running under Xen, for example? If it stops occasionally you’d still have the other non-Xen ones running elsewhere on the network. The main point would be to see how long it stayed up before crashes or server restarts interrupt the service, and to learn about making backups and other house-keeping issues.

I doubt firms would actually use Xen for mission-critical applications in the next few years. Before doing that, they must be sure Xen is stable, performs well enough to handle the tasks, and has management tools to enable IT staff to start, stop, back up and migrate their virtual servers.

More importantly, the application must be at a point in its lifecycle that makes it suitable for migration. There’s probably not much advantage in migrating an application that has only recently been installed on new hardware because critical apps usually need testing and certification before deployment, and who wants to repeat that process unnecessarily? Many firms would wait until a critical app’s server hardware was ready for retirement before migrating.