The platform provides lab management for VMware ESX and Microsoft Hyper-V hypervisors. In fact, it can manage virtual machines on both platforms from the same pane of glass. The company expects within the next 12 months to add support for Red Hat KVM (Kernel-based Virtual Machine), the new hypervisor bundled with Red Hat Enterprise Linux, which marks that OEM's departure from its longtime association with Xen. Surgient has no timetable for Xen support.

From the Surgient console, administrators first outfit servers with a hypervisor. These servers are then added to the inventory of usable systems. According to its capacity, a new server is given an estimate of its capabilities, including what Surgient calls EPU, or effective processing units, which are the smallest divisible unit of computing power. The EPUs, the RAM, and the storage are then assigned to resource pools, which are management entities for hosting virtual machines. As with the other products, configurations of virtual machines can be hand-tooled by the administrator or copied from a library of templates. The virtual router discussed earlier is an optional feature for the configurations. Cloning a running configuration is a simple menu click.

Configurations can be set up to use a physical network address and attached as a WAN segment, so that users can access them transparently, as a wide area network, without awareness that they are using a virtual machine. Surgient uses this capability in house for its own administrative needs.

As I used Surgient, I became intensely aware of how well it has integrated itself into the fabric of enterprise IT. Not only does it support both leading hypervisors, but accessing the consoles of running VMs can be done through a wide choice of options: RDP (Remote Desktop Protocol), VNC, VMware's vSphere console access, or Citrix ICA. Deployment of VMs can be automated within Surgient or via HP Server Automation (HP's provisioning tool for enterprises) or Altiris from Symantec. Like the other packages reviewed here, Surgient integrates with Microsoft Active Directory and LDAP. It also can relay usage and performance data to most BI tools.

While the other packages have some of these IT features, none has the rich scheduling environment that comes with Surgient. The scheduler enables users to schedule a given number of machines at a specific time and be confident the VMs will be available. This option is critical in several use cases, such as education (when a class might need 30 preconfigured VMs at a set time) or doing demos from remote locations.

The only detail that gave me pause was how Surgient handles cloning. This requires some explanation. When a clone is made on VMware vCenter Lab Manager, the system saves only the delta (that is, the changes) from the base template virtual machine. This is called a "linked" clone. The reason for this design is that deltas tend to be small files, and they're easy to store economically and set up quickly.

Performance is the key, but it has a price: complexity. The complexity comes from situations in which the clone is later cloned. In the VMware product, cloning clones creates two or more generations of descendants from the original virtual machine. This works fine. When you boot the VM, the series of deltas are combined transparently with the original virtual machine, and you're good to go, but what happens if a linked clone is deleted?

On VMware's implementation, you cannot delete the original virtual machine if it has linked clones. (The virtual machine will show up as deleted on the console and be unusable, but in the background it will continue to exist as long as it has dependent clones.) However, you can delete one of the intermediate generations of delta files, thereby marooning all subsequent generations of clones on the system. They can no longer boot.

Surgient gets around this problem by allowing only one generation of linked clones. If you clone a virtual machine, it creates a delta file. If you clone the clone, it consolidates the delta file into the virtual machine, then clones the entire VM. This neatly solves the problem, but it incurs a distinct performance penalty: Second-generation clones take a long time to create.

How much this delay is a benefit or limitation depends on how often you need to clone machines. The most common use case for frequent cloning is development and test environments. In the example of the tester cloning a virtual machine for a developer to witness a bug, the developer might then run the clone and in the debugging process take a clone of that virtual machine.

At this point, the developer crosses the threshold where VMware and Surgient take divergent paths. As a user, I prefer the VMware solution because creating a clone at these points is something you want to do quickly. As a manager, I recognise the complications of multiple generations can be costly and represent an occasional burden to IT administrators.

If you tend toward the IT perspective, Surgient has an excellent solution; otherwise, you might prefer the approach taken by VMware or VMLogix.


That concern aside, I find Surgient to be an excellent product. From an IT perspective, it is the most complete package reviewed here, running on the major platforms and offering a broad range of IT hooks.