Monitoring, Management & Location Tracking

The Seven Simple Rules for Virtualizing the AirWave Management Platform (VAMP)

Aruba Employee
Aruba Employee

See also:
AMP on VMware ESX 3.0(i) & 3.5(i)

Compiling a VMware kernel module

The following text is taken from a thread on the AirWaves Forum. To view the full thread including all responses please follow the following link:

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 AirWaves resident expect on server virtualization, I thought Id 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 wont 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, whats 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. AMPs 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 its 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 Id 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, AMPs 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 its inefficient and needlessly slow for a text-based console. Consider, instead, using SSH for access to the AMP command line. Its 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. Its 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 AMPs command line:

# mount /dev/cdrom /media/cdrom

Again from the command line, extract the VMware Tools TAR file to AMPs /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/

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 AMPs 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.

Version history
Revision #:
1 of 1
Last update:
‎06-09-2014 08:50 AM
Updated by:

This is perfect - on one hand I am surprised Aruba doesn't offer more comprehensive instructions on how to do this. On the other hand, I guess most customers aren't 95%+ Windows shops running a VMware environment. Thank you (specifically for rule #6)!!