SUSE Linux Enterprise Server 11: Review
We hit a few snags with SUSE Linux Enterprise (SLES) 11 and its Service Pack 1, especially involving KVM and Hyper-V, but Novell is doing a good job of maintaining SLES as an enterprise operating system
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.
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.
… and under KVM and Xen…
Beginning with SP1, organisations running SLES 11 have the option of KVM as an alternative to Xen, which remains Novell’s primary virtualisation 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 virtualisation options use the same set of management tools, with the biggest difference being the choice between paravirtualized and fully virtualised guest installations when using Xen.
