eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Version 5 of Red Hats Red Hat Enterprise Linux operating system hit the streets last month, complete with a truckload of updated open-source components and brand-new support for server virtualization-courtesy of the Xen hypervisor project.
eWEEK Labs tested RHEL 5 with a particular focus on its new virtualization features. While we think that Red Hat is off to a good start with its Xen implementation, companies in search of an out-of-the-box server virtualization solution shouldnt expect it from RHEL 5.
Compared with VMwares VI3 (VMware Infrastructure 3) and with the Xen-based Virtual Iron and XenEnterprise products weve reviewed, RHEL 5s tools for creating and managing guest machines are pretty Spartan, and our experiences installing and running Windows Server 2003 and RHEL 5 guests contained more troubleshooting and Googling than we would have liked.
However, we expect that any company looking for a general-purpose Linux operating system with solid support and lots of hardware and software certifications would be rather pleased with RHEL 5.
At sites where earlier RHEL versions are already in service, the upgrade should fit in particularly well. Red Hats subscription model has always meant that customers can upgrade between RHEL versions when they want, but the addition of virtualization support offers the alternative of running older versions of RHEL on a RHEL 5 box as virtual machines.
RHEL 5 supports x86 platforms, as well as Advanced Micro Devices Athlon 64 and Opteron; Intels EM64T (Extended Memory 64 Technology) and Itanium II; and IBMs Power, zSeries, and S/390 platforms.
eWEEK Labs tested the 64-bit version of RHEL 5 on an IBM x3655 server with two dual-core Opterons and 3.5GB of RAM; we ran the 32-bit version both in a VMware ESX Server VM and in a guest instance on our 64-bit RHEL test system.
With RHEL 5, Red Hat has shuffled its SKUs around a bit-what had previously been the entry-level ES server version is now just called Red Hat Enterprise Linux. This version is limited to two CPU sockets, and is priced, per year, at $349 for a basic support plan, $799 for a standard support plan and $1,299 for a premium support plan.
This version comes with an allowance for running up to four guest instances of RHEL. You can run more than that, as well as other operating systems, but only four get updates from, and may be managed through, RHN (Red Hat Network). We thought it was interesting how RHN recognized the difference between guests and hosts on its own and tracked our entitlements accordingly.
What had been the higher-end, AS version of RHEL is now called Red Hat Enterprise Linux Advanced Platform. This version lacks arbitrary hardware limitations and allows for an unlimited number of RHEL guest instances per host. RHELs Advanced Platform edition is priced, per year, at $1,499 with a standard support plan and $2,499 with a premium plan.
Xen virtualization
RHEL 5s most headline-grabbing feature is its integrated Xen virtualization support, which enables the product either to host Linux guest instances with Xen-aware kernels or, with the right hardware, to host arbitrary, unmodified guest operating systems, such as Windows.
Support for hosting applications in their own virtual compartments is becoming the norm for server operating systems. Sun Microsystems Solaris 10 has been doing it for more than two years, and Novells SLES (SUSE Linux Enterprise Server) 10 has been providing such support since last summer. Microsofts upcoming Windows Server “Longhorn” also will sport its own virtualization support.
The benefit of using virtualization within general-purpose operating systems is that these products typically offer broader hardware support than do bare-metal or appliance-type virtualization products. The downside is that operating systems, such as RHEL5, tend to offer virtualization services like erector-set pieces-virtualization-savvy OSes can deliver results similar to a product like ESX server, but theres some assembly required.
Once wed gotten our instances configured just so, they ran well, and hosting these guests atop a full-blown operating system meant access to all the facilities that RHEL 5 has to offer-for instance, a full range of storage options, including RHELs new iSCSI initiator. The configuration road, however, was certainly steeper than that for other products weve tested.
There are separate command-line and graphical interfaces for creating and manipulating guest instances running on RHEL 5. The products graphical virtualization manager starts you out with a dialog that offers to link you to a local Xen domain, a remote Xen host or to another sort of hypervisor. Only the first of these three options works-the other two are grayed out pending some future update.
Next Page: Configuration consternation.
Configuration Consternation
We would have liked, at least, to be able to take control of a remote RHEL 5 Xen host. Wed initially configured our Xen host server to be headless, with the intention of controlling it from a separate RHEL 5 installation, but we ended up installing a GUI on that machine to test the client.
Once we were past the connection screen, we could view information on running guest instances, as well as create new instances.
For paravirtualized guests-the only sort of guest you may install on older hardware that lacks AMDs or Intels virtualization extensions-we had to point the management client at an FTP, HTTP or NFS (Network File System) share into which wed dumped all the files from RHEL 5s six installation CDs. Novells SLES 10 offers a utility that automates creating install sources, and wed have liked to see a similar time-saving utility in RHEL 5.
For fully virtualized guests, we could link our new guest instance to a CD image and install from there, which we found easier. We ran into a snag, however, as wed created our paravirtualized guest install source in the same directory where we were storing our installation images. Exploded install source and disk images must be in separate folders for those images to be accessible during installation.
Along with the install source, we could specify a kickstart configuration file-kickstart is Red Hats scripted installation facility.
After configuring our install source, the client asked us to assign our guest instance some storage, either an existing physical partition or an image file. The client didnt offer us any suggestions on where to store our image file, but the location does matter, as we learned when we booted up our instance.
RHEL 5s SELinux (Security Enhanced Linux) policy expects images to live in /var/lib/xen/images, and images stored elsewhere-such as ours-require relabeling to avoid SELinux errors.
While this was a good opportunity to see RHEL 5s new SELinux Troubleshooter in action, it would have been helpful if RHELs virtualization manager had given us a heads up about this earlier. After configuring storage, the client asked us to set the startup and maximum memory allocations for our new instance and to configure the number of virtual CPUs to expose to our guest instance.
The client didnt offer us much in the way of network configuration options-our instances defaulted to a single NIC in a bridged networking configuration. Other configurations meant hitting the command line, and the documentation, to sort things out.
We installed a fully virtualized instance of Microsofts Windows Server 2003 and at first could not boot beyond the initial blue installer screen. A bit of Web searching revealed that, when the Windows installer first loads, we had to hit the F5 key and select the Standard PC Hardware Abstraction Layer.
After that, the process proceeded normally for a while, but we werent out of the woods yet. When the Windows installer rebooted itself-a normal part of installation-our instance didnt restart to continue the process.
Whats more, our half-installed Windows instance wasnt listed in RHEL 5s virtualization manager. We turned to RHEL 5s command-line virtualization control tool, virsh, and directed our machine to start our Windows instance. The instance started up, and we connected to it via VNC (virtual network computer) remote control software thats rolled into most Xen implementations.
We werent back in business yet, though, because the graphical client appeared to have assigned the Windows installation disk to our instance only temporarily-we had to edit its configuration file to reassign the Windows disk and then restart our instance to finish the process.
Lockdown capabilities
One of RHEL 5s most distinctive features is its support for SELinux, which bolsters the security of the Linux machines on which its deployed by meting out to applications and users only those rights explicitly granted by policy.
RHEL 5s default SELinux policy covers a limited set of system services, and we could enable or disable specific protections through RHELs security-level configuration tool, as well as step up to a separate, strict policy that covers everything on the system. New in RHEL 5 is an additional SELinux policy for implementing MLS (Multi-Level Security), which we did not test.
We did have a chance to use RHEL 5s handy troubleshooting tool for SELinux, which prompted us from the notification area in our system tray when an application we ran triggered an SELinux denial. This is how we straightened out the issues we encountered with appropriate storage locations for our Xen instances.
Advanced Technologies Analyst Jason Brooks can be reached at jason_brooks@ziffdavis.com.