Akimbi makes virtual labs real
Akimbi Slingshot brings impressive automation to virtualized testing environments
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.
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.