The local MITRE lab in Orlando is organized around six Dell 690 workstations (no longer manufactured), each outfitted with one quad-core Intel Xeon 5140 and 32 Gb of memory. Two of those machines have Red Hat Enterprise Linux (RHEL) 64-bit Server 5.5 installed while the other four have RHEL 64-bit Client 5.5. Because of the wealth of memory on each workstation I've also installed VirtualBox on every one. Through VirtualBox I've been able to install additional Linux and Windows XP virtual machines across all of them. As a consequence I've been able to build complex networks for test and evaluation.
The guest operating systems installed to date are CentOS 5.4 64-bit, Fedora 12 64-bit, OpenSUSE 11.2 64-bit, RHEL 5.5 Client and Server 64-bit, Ubuntu 9.10 and 10.04 64-bit, and Windows XP 64, SP2. In the case of Windows XP, each Dell came with a licensed copy of Windows XP 64. When the decision was made to install RHEL as the host OS, then the Windows instances were re-hosted on each box as a virtual machine, based on the license attached to each chassis. This is far more flexible than trying to install RHEL as part of a dual-boot system; we seldom use Windows XP 64, and when we do we can run the WinXp 64 VM, do what needs to be done, and then just shut it down when finished without having to reboot the box.
Of all the VMs that I've installed to date, the easiest to install and work with are the RHEL/CentOS-based VMs. Fedora comes in a very close second, while the others show a few more quirks executing as a VM as opposed to a native install.
I'd like to draw special attention to OpenSUSE with regards to behaving as a VirtualBox VM. OpenSUSE 11.2 (and 11.3 M6) have VirtualBox Guest Additions installed by default. This is sweet because after OpenSUSE is installed and restarted, OpenSUSE is already in seamless mouse support and automatic screen resolution adjust when you resize the VM window. That's a very nice feature. All other VMs (including RHEL) require a second step where, as root, you install the VirtualBox Guest Additions and restart the VM one more time for them to take effect.
My reasons are varied as to why I install and use other Linux distributions.
- First and foremost, there are times we need more than six systems. The Dell machines can easily run three VMs plus the host OS, giving me up to 24 different logical machines.
- There are times where a given application that demands its own machine must be installed and run. The easiest solution is to pick a generic Linux distribution VM, clone it, and install the application. That VM can then be hosted on any of the six boxes, and when finished put back on the shelf until the next time it's needed.
- We only have six official paid-for RHEL licenses. While I have other RHEL instances installed for testing, for general use CentOS 5.4 is used as a VM surrogate for RHEL 5.4/5.5. So far CentOS appears to behave identically to RHEL, which it should, considering it is built from the RHEL sources. If I need to test something critical that specifically requires RHEL then I'll fire up a RHEL VM and test. But for general work I'd rather use CentOS and remain on the conservative side of licensing interpretation. RHEL/CentOS also supports Google Earth 5.0 (not 5.1) which we sometimes need.
- As noted above we have six WinXP 64 licenses, one/box. As a consequence I only run one Win VM/box, and that's based on the license attached to that box. No clones of the VMs. We seldom have use for Windows XP 64, running our tools and applications primarily on Linux. And before anyone asks, no, Wine is totally inadequate for running any substantive Windows applications.
- Ubuntu 10.04 is so far the best version of Ubuntu to run as a VM. The primary reason to have it installed is to host a decent version Google Chrome for Linux.
- Fedora 12 supports some tools and processes that were specifically developed for that distribution.
- OpenSUSE 11.2 is my alternative distribution in case something goes weird. The fact it installs out-of-the-box as a full-blown VirtualBox VM makes it a keeper. I wish all the distributions were that way, but I won't hold my breath.
Here's where some of the quirks of working with Ubuntu 10.04 as a VirtualBox VM come into play. The version of Chrome running in the Ubuntu VM was downloaded form Google's download page, not installed via the Ubuntu software manager. The biggest reason is that Ubuntu wants to install supporting DEBs from the DVD from which Ubuntu was originally installed. And that's great, except Ubuntu insists on seeing the DVD in /media/cdrom, instead of where it shows up when the DVD is placed in the host machine's player, /media/Ubuntu 10.04... I'm sure there's some sort of configuration buried in Ubuntu to point to the correct mount, and I'll get to it eventually, but the fact it shows up at all is annoying, and no other distribution has this issue when running as a VM.
Another gotcha occurred when Ubuntu automatically updated itself. One of the updates was the kernel, and sure enough, I had to re-install the VirtualBox Guest Additions in order to get seamless mouse and automatic screen resolution adjust.
I started Firefox along side Chrome to do a cursory comparison. Right off the bat you'll see that Chrome 5 beta ignores the window decorations, placing the window controls in the right-hand corner. Other than certian operational differences they operate pretty similarly, with the notable exception that Chrome runs faster. I've made no decision as to whether I like the new Ubuntu theming; it's different but not radically so from any other distribution.
Some have asked why I didn't use VMWare or take advantage of the VM framework built into RHEL. The answer, simply put, is that VirtualBox is a lot simpler to acquire, install, and operate than either VMWare or RHEL's solution. Cloning VMs and transporting running VMs between machines are easy tasks; I've just gotten into the habit of turning to VirtualBox for what needs to be done. Unfortunately one of the other engineers who uses VirtualBox quite heavily in the lab has complained of instability issues, which I need to investigate and resolve. Just because it's good for me doesn't mean it's the best long-term solution for the lab. If I'm forced to migrate from VirtualBox due to performance issues, I'll investigate RHEL's built-in VM solution next.