Configuration Consternation

By Jason Brooks  |  Posted 2007-04-09 Print this article Print

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.

Click here to read more about Red Hat Enterprise Linux 5.

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

Check out eWEEK.coms for the latest open-source news, reviews and analysis.

As Editor in Chief of eWEEK Labs, Jason Brooks manages the Labs team and is responsible for eWEEK's print edition. Brooks joined eWEEK in 1999, and has covered wireless networking, office productivity suites, mobile devices, Windows, virtualization, and desktops and notebooks. JasonÔÇÖs coverage is currently focused on Linux and Unix operating systems, open-source software and licensing, cloud computing and Software as a Service. Follow Jason on Twitter at jasonbrooks, or reach him by email at

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel