Successes and Failures
SUSE Linux Enterprise Server 11 Gets SP1 Flexibility
With the first service-pack update to its SUSE Linux Enterprise Server 11, Novell has stuck with its philosophy of appealing to as many different server constituents as possible, with a particular focus on assuming as many different virtualization host and client roles as possible.
Between the OEM arrangement with VMware for SLES that Novell announced in June and the goodies that SUSE Linux Enterprise 11 Service Pack 1 brings relating to Xen, KVM and Hyper-V, SUSE's enterprise-oriented Linux offering merits evaluation by organizations running virtual infrastructures of all stripes.
Of course, the more broadly a vendor spreads its attention, the more difficult it can to really to nail any one area. In my tests of SLES 11 SP1, I encountered a few snags-particularly in the KVM and Hyper-V quarters outside of Novell's preferred Xen terrain-but I was impressed overall by the progress that Novell has made maintaining in SLES as a leading enterprise operating system amid industry shifts around virtualization and cloud computing.
Versions of SLES 11 are available for the x86, x86_64, Itanium, IBM PowerPC and zSeries processor architectures. I tested the x86_64 version of SLES 11 SP1 on a dual-processor server with 4GB of RAM, which I pressed into service as first a KVM virtualization host and then a Xen virtualization host. I also tested SLES 11 SP1 as a guest operating system running under those KVM and Xen hosts, and as a guest machine running under Windows Server 2008 R2 with Hyper-V.
SLES 11 is sold by annual subscription, with pricing that differs based on support level and processor architecture. For x86 and x86_64 architectures, subscriptions range from basic plans that include 30 days of telephone and e-mail-based support and cost $349 per system to priority subscriptions that cost $1,499 per system and include 24/7 telephone and e-mail support over the full support term.
All subscriptions include access to product updates and allow for an unlimited number of hosted virtual machines. For more on SLES 11 pricing, go here.
SLES in the lab
I kicked off my tests with Hyper-V. Owing to the infamous Linux collaboration arrangement that Novell and Microsoft began back in 2006, I expected the path to running SLES under Hyper-V to be particularly smooth. Right off the bat, I was pleased to find that the so-called enlightened drivers required to use full-speed virtual components under Hyper-V were automatically installed on my test instance.
I was less pleased to find that while the driver required for my test instance to use its virtual network interface came preinstalled, my test system needed some prodding before it would use it. I had to issue the command "modprobe hv_netvsc" to get my SLES instance to recognize its network interface. I then edited my instance's /etc/sysconfig/kernel file to load the module automatically upon subsequent boots.
Elsewhere on the virtual hardware front, I encountered some frustration with the lack of mouse support for Linux under Hyper-V, which I experienced when my first SLES booted up by default into a graphical interface. Microsoft does not provide a Hyper-V driver for mouse support, and the input driver that Citrix's XenSource developed under its Project Satori doesn't work with the Version 2.6.32 kernel that powers SLES 11 SP1.
I was able to interact with the graphical interface of my SLES instance machine by enabling its VNC-based remote administration feature, and I could administer the system easily through a command line SSH (Secure Shell) session. The system's setup tool, YAST, comes with a nifty terminal-friendly version of its interface. However, both of those routes require network access, and as I mentioned above, I encountered a few issues there, as well.
Successes and Failures
These issues were easy to resolve, after which my Hyper-V-based SLES instance performed well. The instance served me well as installation server for my subsequent SLES test machines, and I added the instance to and authenticated against the Active Directory domain in our lab without difficulty. With that said, I was disappointed by how little discussion of Hyper-V appeared in Novell's documentation. I searched the SLES 11 documentation on Novell's Website, and the term "Hyper-V" appeared only once, in the context of running guests under a Xen host. In fact, it turned out that the most helpful source of information I found on Linux and Hyper-V was a blog post about running Ubuntu guests under the Microsoft hypervisor.
Beginning with SP1, organizations running SLES 11 have the option of KVM as an alternative to Xen, which remains Novell's primary virtualization platform option. Novell did well to extend at least a tentative embrace to KVM, since Red Hat is in the process of shifting away from Xen to focus exclusively on KVM. Canonical has also selected KVM as the primary virtualization host technology for Ubuntu Linux, and I expect to be seeing a lot more of KVM in the future.
I installed SLES 11 SP1 on a dual-processor tower server and fired up the Install Hypervisor utility within the always-helpful YAST suite. The utility offered me a choice of Xen or KVM. I chose to install KVM, and the installer went about loading the necessary drivers and management packages-more or less the same group of software I'm accustomed to installing on a Red Hat or Canonical Linux distribution, anchored by the libvirt management library and including the graphical virt-manager tool.
One of the compelling features of the libvirt library is the ability to access and manage remote hosts from a local virt-manager instance, although I've had mixed success getting this feature to work in past implementations. This time, I managed to access and manipulate my SLES-based KVM instance from my Ubuntu 10.04 and Fedora 13 clients, but only after installing on SLES the package netcat-openbsd from the repositories of SLES 11's community-oriented sibling distribution, OpenSUSE 11.3.
When I tried the same remote access operation from one SLES instance to another, I was able to connect without issue (and without installing the additional package) but I couldn't create a new VM. The copy of virt-manager running on SLES complained that "a hypervisor is not running." It seemed that virt-manager was failing to distinguish between the client, where there was no hypervisor installed, and the remote host.
After testing out KVM on SLES 11 SP1, I swapped over to Xen on the same system. Both virtualization options use the same set of management tools, with the biggest difference being the choice between paravirtualized and fully virtualized guest installations when using Xen.