Novell's Suse Linux Enterprise Server 10 (SLES 10), launched on Monday 17 July, is the first commercially supported Linux distribution to include the open-source Xen server virtualisation technology. Other big changes include the addition of Oracle's Cluster File System 2 (OCFS2), which enables multiple servers to simultaneously use the same disk storage. Security also gets a huge boost thanks to the integration of Novell's AppArmor application control tools, and the addition of a full set of CIM (Common Information Model) interfaces to Xen paves the way for third party virtual server management tools.

We tested SLES 10 by installing it on a twin Xeon server system fitted with 3.6GHz processors and 4GB of RAM. The Suse setup tool detected our server's LSI SCSI controller and the pre-existing installation of Windows, and resized one of the Windows NTFS partitions to make room on the hard disk for the SLES software.

The two areas of interest in SLES 10 are its Xen support and AppArmor subsystem. We tested the Xen support by creating a Xen virtual machine (VM) without referring to any documentation. As IT Week Labs is a long term user of Suse Linux software, an educated guess informed us that the best place to look for Xen support was in Suse's Yast tool, which performs a similar function for SLES as the Control Panel does for Windows.

The Yast System tab has a new option for Xen management. When we first clicked on this option a dialogue box told us that our server was not configured to run Xen. Having accepted the offer to fix this, Yast installed the missing components and asked us to reboot the system and use a new option at the boot prompt to load the freshly created Xen kernel.

With the server rebooted and running a Xen kernel, pressing the Xen management button produced a dialogue box listing existing VMs and offering buttons to add, delete, start, stop and view a VM. Currently, Xen supports the viewing of VMs using a Linux text console. Firms wanting a VM with a graphical user interface would need to configure the VM with a third party remote desktop tool, such as VNC or Windows' remote desktop protocol. We used the 'add' button to create a new Xen VM. A dialogue box then gave us the choice of installing the VM from installation disks or by copying a pre-built VM from another system. We took the first option and put the first SLES 10 installation disk into the CD-ROM drive. We gave the default answers to various questions from the SLES installation tool, and some fifteen minutes later we had our first Xen VM up and running SLES 10.

Our tests of the AppArmor subsystem were equally impressive. We created an AppArmor policy for the Firefox web browser using the Yast AppArmor wizard. First, this asked us to locate the executable file over which the new policy would exert control. Having done this, the wizard asked us to run Firefox for a short while before pressing a button to create the new policy based on our activity. We browsed to a few web sites and told the wizard to make the policy. It then listed all the system calls made by Firefox, asking us to confirm they are safe to add to the policy. We took the default answer for each question, and then restarted Firefox, which was now working according to its AppArmor policy.

Although we didn't have time to test them before going to press, SLES 10 includes tools to help build an effective Xen server farm that can handle automatic failover of failed virtual servers from one host to another. A basic setup for this would be to configure one SLES 10 server with an OCFS2 volume and set it to work as an iSCSI storage server. Two or more Xen servers would then be configured to connect to the OCFS2 storage using iSCSI, and to monitor each other using software in the SLES stack called 'heartbeat'. A command line tool can be used to cause a running VM to migrate from one host to another without requiring the VM to shutdown.