With many IT departments embracing virtualization, AirWave fields an increasing number of questions from clients wanting to know if they can run the AirWave Management Platform (AMP) as a virtual machine on VMware or on another virtual platform. The simple answer to the question is a resounding, “Yes! — AMP runs just fine as a virtual machine.” As AirWave’s resident expect on server virtualization, I thought I’d take a few moments on a lazy Sunday to share with the AMP community what I call my Seven Simple Rules for running AMP as a virtual machine. Here they are:

Rule #1 - Choose Your Virtual Platform Carefully.

A few years ago virtualization choices were limited, with VMware dominating the scene. Today, the number of virtual software platforms has exploded, with VMware still leading the pack of closed-source and open-source virtual machines. But AMP is both a memory-intensive application as well as a CPU-hungry program — this tends to place hard bounds on which virtual platforms are well-suited to running AMP as a virtual machine.

If you were thinking of running AMP on any of the free offerings from VMware, think again; while AMP will run on these platforms, it won’t run well. In the lab, we’ve tested AMP on a VMware Server, and ran into several post-install problems, including scaling limitations, memory constraints and an annoying clock-drift problem when running as a guest OS on Windows operating systems. For best results, you definitely need a VM that will allow you to virtualize AMP with a minimum of 2 GB of RAM and preferably at least two virtual CPUs. VMware’s ESX offers these options, as do a few other virtual machine platforms.

Rule #2 - Remember the Hardware Requirements

One of the oft-touted advantages of virtualization is that virtualization gets you off the hardware hook; with a virtualized application, hardware isn’t supposed to make a difference, and both operating systems and applications can gain true independence from hardware. However, what’s true for device drivers and system architectures isn’t always true for scalability. As noted above, AMP will not run well on your average $200 PC-of-the-Week special. If you want to run AMP as a virtual machine, you need to keep the hardware requirements firmly in mind.

Virtualization enacts slight a tax for hardware independence — typically, 256 MB of RAM, 10% of the CPU and a few gigabytes on the hard disk. That may not sound like much, but it means that you’ll need a beefy box to run AMP in a virtualized environment. We recommend you virtualize AMP on dedicated hardware, and that you leave some room for expansion. Think about systems with at least 4 GB of RAM and preferably a quad-core processor. AMP’s published hardware requirements are your best bet for properly scaling the system you’ll use to virtualize AMP.

Rule #3 - You’re Entering the Red Hat Zone

The AMP install ISO is based on a derivative of Red Hat known as CentOS. The advantage of CentOS is that it’s free to redistribute and it costs nothing to upgrade as bug fixes and new Linux packages become available. The current version of the AMP ISO (as of AMP 5.2.3) runs CentOS 4.3, which maps directly to Red Hat 4.3. The next scheduled release, AMP 5.3, will run CentOS 5.0, which maps to Red Hat 5.

Whenever you’re presented with OS options by the virtual machine, usually during install, choose the option for Red Hat 4, or Red Hat 5 if you’re using an AMP ISO based on the CentOS 5 system. The same applies to installing VMware Tools (more on this later).

Rule #4 - Use Expanding Disks

Most VM implementations allow you to choose to use an expanding disk, or allocate the entire disk space during install. Unless you have a SAN-based virtual infrastructure, or have a complex disk partitioning scheme in mind, expanding disks offer far more flexibility at very little cost in performance.

The first beauty of expanding virtual disks is that they start out small, making it much easier to port them from machine to machine via LAN, WAN or even old-style SneakerNet with an external drive. The second beauty of expanding disks is that they allow you to create large partitions for future growth without having to immediately allocate the byte space on a real disk. The performance penalty, on the other hand, doesn’t seem to be much at all. However, not setting up a large enough partition for AMP at the beginning can be a real show-stopper — there are ways to bump-up partition sizes post-install, but none of them are what I’d call easy. Save yourself the hassle and start with a partition size large enough to accommodate both current and future needs, and let the VM expand the disk file as needed.

Rule #5 — Beware the Virtual Console

All virtual machine implementations offer an interface to the console of the guest OS, essentially a window displaying what you would see on the screen if you could actually attach a screen to a running virtual OS. In the case of AMP, virtual console displays are unnecessary, and can slow down your work with a virtualized version of AMP.

Most virtual console displays assume that you’re running a guest OS offering a graphical interface at the system console, which is not the case with AMP. Technically speaking, AMP’s console runs in a Linux/UNIX mode known as INIT 3, which is a purely text-based console mode. VMware’s remote console application, to use as an example, creates a screen scrape of the guest OS virtual console and then throws those bits across the network for reassembly on your console viewer application. This works great for a GUI-based console, but it’s inefficient and needlessly slow for a text-based console. Consider, instead, using SSH for access to the AMP command line. It’s faster, it uses far fewer network resources and in the limited number of cases where you need to access AMP at the command line instead of via the web-based GUI, SSH is a much better method of doing so. PuTTY is a great Windows SSH application, and you’ll find it faster and easier to use than a virtual console.

Rule #6 - Installing VMware Tools in a Text-based Environment

I always recommend installing VMware Tools (or other like-minded virtual machine post-install packages) on virtualized AMPs. Unfortunately, VMware’s instructions for doing so in a non-GUI environment are incomplete as they assume a desktop, etc. Have no worries though; it is possible to install VMware Tools on a virtual AMP. It’s also surprisingly easy, if you know the method.

First, while AMP is running use the VMware console to start the VMware Tools install. Next mount the VMware tools ISO at the AMP’s command line:

mount /dev/cdrom /media/cdrom

Again from the command line, extract the VMware Tools TAR file to AMP’s /tmp directory:

cd /tmp/; tar -xvzf /media/cdrom/VMwareTools-7.6.2-62573.tar.gz

(Note that the exact name of the VMware Tools TAR file will very likely be different from the one in the example above; use the full filename of the gz file you’ll find in /media/cdrom)

Finally, run the VMware Tools install script and choose all of the default options during install:

/tmp/vmware-tools-distrib/vmware-install.pl

Rule #7 - Learn to Love Disk Image Files

One of the things I like best about virtualization is how easy it is to quickly install an operating system using just a disk image (ISO). I always surprise my colleagues at AirWave with how quickly I can install a test AMP using nothing more than a disk image and a free virtual machine.

Depending on how much disk space you have available, consider keeping around an AMP ISO and a copy of your virtual machine disk. There are some interesting tricks you can do with a virtual AMP that are difficult or impossible to pull-off with your typical system-based installs. Considering an upgrade to a new version of AMP? Test it on the AMP virtual disk copy first by building a new virtual machine around it, without ever having to shutdown your production AMP. Or, as an alternative, build a fresh AMP install with the ISO, then load an AMP backup to check the upgrade. Want to know if a memory upgrade will improve AMP’s performance? This is easy to test with a virtual machine. With AMP and a virtual disk image file, the sky’s the limit to what you can do.