SUSE Linux Enterprise Server (SLES) 11 was released almost three years ago, based on Linux kernel 2.6.27, and the first service pack in May 2010 re-based the kernel version to 2.6.32. Now SLES 11 SP2, the first update since SUSE became a division of Attachmate, swaps this kernel for version 3.0. This adds support for the newest Intel Xeon and AMD Opteron processors, as well as some interesting features such as Transparent Huge Pages (THP), CPU and memory offlining and per-CPU network load balancing.
Such a big jump in kernel version between service packs is not common for enterprise Linux distributions, which are usually quite conservative. For instance, Red Hat Enterprise Linux 5 is still using kernel version 2.6.18, even for its 8th update (RHEL 5.8), released a week after SLES 11 SP2, and in the same way RHEL 6.2 is still using kernel version 2.6.32. Of course these kernel versions contain a lot of backported features from newer kernel versions, but it’s a lot of work to patch these features in and to keep maintaining them.
Instead of backporting and maintaining all those interesting features, SUSE’s engineers have decided to use Linux 3.0 for SLES 11 SP2. This wasn’t done rashly: they did an extensive code review of Linux 3.0 and verified that the kernel’s Application Binary Interface (ABI) is completely compatible with SLE 11’s original 2.6.27 kernel. This guarantees that all software that ran on this kernel can expect exactly the same behaviour from the newer kernel release. So any software that has been certified for SLE 11 is still certified for SLE 11 SP2.
Ext3 is still the distro’s default filesystem, but this is the first time Btrfs (which was introduced as a technology preview in SP1) is officially supported. However, SP2 still uses GRUB Legacy which can’t boot from Btrfs, so when you choose Btrfs in the installer, SLE uses it as your root file system but creates a /boot partition with an Ext3 filesystem.
SUSE has also integrated the Snapper tool that it introduced in openSUSE 12.1 to manage Btrfs snapshots and rollbacks. The basic idea of Snapper is that it automatically creates a snapshot before and after running YaST or Zypper, compares the two snapshots and therefore provides the means to revert the differences between these two snapshots. You can list all the snapshots, see the differences between snapshots and roll them back using a user-friendly YaST module or with the commandline snapper tool. There’s just one caveat: because the boot partition doesn’t use Btrfs, you can’t roll back kernel updates or changes to the boot configuration.
Thanks to Snapper, you can mess up system configuration changes or package installations or updates without having to restore from an old backup and risking to lose some files. Just revert to the snapshot before your problematic change and you’re fine. But Snapper also helps with audits: it’s very easy to discover which changes were made by which YaST or Zypper transaction. Snapper also creates cron jobs for periodic snapshots (which is configurable), so you’ll be able to undo other manual changes too.
SP2 still offers Xen and KVM for virtualization, but it also introduces support for LXC (Linux containers), which is a form of operating system-level virtualization: when you create LXC containers, they are separate virtual servers, but all running on the same underlying Linux kernel of the host system. This lightweight virtualization method has a negligible overhead, as it’s essentially a “chroot on steroids”. On SP2, you can use LXC to isolate various system services from each other.
With the support of Btrfs and LXC, SLES 11 SP2 is trying to get users to migrate from Solaris to Linux. It remains to be seen whether Solaris users really take the bait, because ZFS and Containers/Zones are more powerful than their Linux counterparts. Compared to its enterprise Linux competitors, though, SP2 has a unique selling point with Snapper.