Virtual Iron Xen offers topnotch security, policy controls

Philosophically speaking, Virtual Iron is different from the other hypervisors tested because it sets up a hypervisor server farm that is managed through a direct-control application over a private link. The Virtual Iron 4.4 Enterprise Edition we tested requires a separate physical machine used as management server. In turn, this server controls what Virtual Iron calls nodes — a 64-bit hypervisor VM-hosting servers. The VMs running on top of these nodes are still referred to as guests.

Virtual Iron uses a master/slave configuration where servers use Preboot eXecution Environment (PxE) boot mechanisms to start their initial program loading, and then they become substrates for virtualization. This means that Virtual Iron slave servers have two networks, a public one that faces the world and a private network used for communication with the master (a machine where Virtual Iron's management application, the VI-Center console, is running).

Virtual Iron platform support has two considerations, one for the Virtual Iron VI-Center and the other for managed nodes.
The VI-Center must be installed on a machine with RHEL 4 (32- or 64-bit), Windows 2003 (32-bit), or SLES 9 (32- or 64-bit) -- all of which are older versions of these operating systems.. To use VI-Center, we also needed to have Java 1.5.0 installed.

As for the managed nodes, you need at least 2GB of RAM, an Intel-VT or AMD-V processor, either SATA or SCSI drives, and at least two Ethernet ports. A full listing of the hardware supported can be found on Virtual Iron's Web site.

The guest operating systems supported include RHEL 3 and RHEL 4 and 5 (32- and 64-bit); SLES 9 and 10 (32- and 64-bit); CentOS 4 and 5 (32- and 64-bit); Windows Server 2000; Windows XP; and Windows Server 2003, 2008 and Vista (32- and 64-bit). All must run fully virtualized because the Virtual Iron hypervisor does not support paravirtualization yet.

Like Citrix's XenServer, Virtual Iron's Java-based management tools are included with the license. Although we didn't run into as many configuration errors as we did in our testing of XenServer, we did have our share of difficulties using Virtual Iron's Java-based GUI.

To get the Virtual Iron installation off the ground, we had to create a data center — basically an object in which the nodes are virtually held and from which they are managed. In turn, the nodes use PxE methods to boot, find the Java-based management server and take directions from it. You also use VI-Center to build and provision new VMs that will reside on each node.

We attempted to set up shared storage between nodes, but were unable to use NFS because it's not supported. So, we moved on to iSCSI connections. To set iSCSI up, we had to create a new network within the GUI and check the iSCSI box — which then takes up another server Ethernet port. Luckily, we could still use that same network link for connecting to the Internet or the LAN for our VMs, although the company doesn't support or recommend this because it's likely to clog the port with a combination of network or SCSI-targeted data communication. Using Virtual Iron's recommended construction, we occasionally lost iSCSI links.