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.
