Akimbi makes virtual labs real

Akimbi Slingshot is one of several products in a nascent product category called virtual lab automation. Slingshot and other tools, such as Surgient’s Virtual QA/Test Lab Management System (VQMS), enable IT test sites to make good use of virtualization technologies by simplifying the process of configuring, deploying, capturing, and simultaneously running multiple VMs.

Slingshot, aimed squarely at environments such as software development and testing, software evaluation projects, and application configuration, is especially good at simplifying the assembly of multi-VM configurations (possibly running on several host systems) and managing and deploying them as a single unit. It also has remarkable snapshot capabilities, combined with a feature that enables multiple identical snapshots to run at the same time. However, Slingshot has a frustratingly high number of rough edges and it lacks a few key enterprise features.

Slinging VMs

Slingshot deploys on an architecture that includes three kinds of servers (all of which can exist on the same physical machine). First is the Akimbi Slingshot server, which runs on Microsoft Windows Server 2003 (a limited version can run on Windows XP), and hosts the software. It runs the main console from which virtual machines are directed.

These virtual machines execute on so-called managed servers, which are systems that run either Microsoft Virtual Server 2005 or VMware GSX Server. Configuration files and snapshots of executable VMs are kept on what Akimbi calls storage servers, of which Slingshot inexplicably supports a maximum of only five instances.

The general idea is that you can easily deploy a configuration involving many virtual machines across any or all of the managed servers. An administrator at the Akimbi console manages a configuration, which is the basic unit in the Akimbi model. To add new VMs, simply drag and drop them into the configuration. You can start them up collectively or individually, deploy them in different ways, reconfigure and redeploy them, and, most critically, you can take snapshots of the entire configuration at any point in its operation.

These snapshots are important, all the more so because Slingshot manages them elegantly. Suppose, for example, that you’re experiencing a problem with a J2EE installation. You replicate the setup, which includes, say, the application server on one VM, the database server on another, and several client machines exercising the application each in their own VM. As soon as you hit the bug, you take a snapshot of this configuration. This snapshot is stored as a delta file, saving only the differences from the original VM templates and thereby taking up little disk space.

You can redeploy this snapshot whenever you want and step through the problem. The ingenious aspect of this is that you can redeploy the snapshot even while the original configuration is still running. This mirror deployment requires a bit of magic because the new snapshot containing the duplicate VMs uses the same MAC (media access control) and IP addresses as those still running.

Slingshot handles this conflict with what it calls a fence, a software router placed in the configuration. At deployment, this virtual router performs network address translation for the whole configuration and also remaps the MAC addresses to any systems outside the configuration. To make sure these MAC addresses do not conflict with those of other devices that could be running simultaneously, Akimbi obtained its own OUI (Organizationally Unique ID) -- the vendor-specific prefix of MAC addresses assigned by the IEEE -- and remaps the MAC addresses from that range.

The management console from which VMs are built, and where configurations are created and deployed, is a model of simplicity. The operations are easy to learn. They mostly involve dragging and dropping and clicking on menu picks and checkboxes. Especially useful is the cloning of existing machines, which also uses deltas from the original configuration. This design makes cloning quick and easy, and it enables you to store dozens, even hundreds of VMs without swamping available disk space.

Not All Joy and Bliss

Slingshot does have a few holes and several rough edges. Its biggest shortcoming is its lack of a reporting system. The closest you get is a log that provides only basic information. Also, the management console will not allow you to see a VM screen at full size. To do this you must install remote-access software and burrow in that way. In addition, Akimbi does not allow you to assign a specific MAC address to a deployed VM. This limitation can lead to complex roundabouts if the licensing mechanism requires a known MAC.

Several operations were far more difficult than they should have been -- installation, in particular. Despite using a fresh copy of Windows Server 2003 to host Slingshot and choosing only default options, the software generated many error messages. None of these error messages was documented. Given that most users will not have installed anything like Akimbi before, each of these undocumented errors is a show-stopper. I also stumbled across numerous small bugs in the interface, such as incorrectly reporting the number of processors on the host system, not graying out invalid menu options, and the like. Finally, I was disappointed that Slingshot supports only one version of Microsoft Virtual Server and exactly one version of VMware. Later releases will broaden the support for hypervisors and will one day include Xen.

Despite these problems, Slingshot is a good product that handles configurations and deployments without error. Even if you never use the fence feature or the snapshot capabilities, Akimbi Slingshot will pay for itself by the ease with which you can set up, deploy, and manage configurations. It should be evaluated for all enterprise lab settings.