I built several Linux and Windows VMs, both 32- and 64-bit, and found the experience straightforward and easy. I had problems booting from ISO images in many cases, though direct CD and PXE installations were no problem. Both Windows and Linux guests are supported with full hardware virtualization, unlike Xen's paravirtualized Linux guests, and the OS support is also broader than Xen's. On the other hand, the VS Tools drivers that can be installed in the guest OS only support certain distributions, and even then, only specific kernels on specific distributions. Thus, kernel upgrades to Linux VMs may result in an inoperable VS Tools installation. VMware overcomes this problem by compiling kernel modules within the guest as needed. Virtual Iron offers new VS Tools packages for specific kernels on its Web site; it also offers the VS Tools source code for customers needing to perform manual compilations, but this process isn't necessarily straightforward.

Click for larger view.

Configuring both local storage and SAN disk is much improved over previous releases. Volumes can now be named, whereas they were previously designated only by long random ID strings. The iSCSI implementation is also well done. Once a designated iSCSI network has been defined, specific ports on the physical servers can be mapped to that network and an iSCSI target configured. Upon rebooting the physical servers, LUNs (logical unit numbers) on the iSCSI SAN are mapped, allowing logical disks to then be created on the LUN. Further, iSCSI passthrough is supported, giving VMs direct access to iSCSI LUNs.

Tripped up
I did run into some significant problems with Virtual Iron. It seems that Virtual Iron's management framework uses the MAC (media access control) address of the management interface on each server as a unique identifier. When I swapped out interfaces on one of the servers, I suddenly had three orphaned VMs and duplicate entries for their physical host. After discussing the problem with Virtual Iron, it became clear that the easiest way to fix the problem was to reinstall the management server. It's possible to manually alter the management server's database to solve this problem, but it's far simpler to reinstall, rediscover the hardware resources, recreate the VMs, and remap the disk volumes. Taking this simpler route, I was able to retrieve all the orphaned VMs, although all disk identifiers were wiped out, leaving me guessing which disk volume belonged to which VM.

During this adventure, the management interface exhibited some very odd behavior, even locking up a few times. All in all, this experience proved to be a mixed bag: It's disconcerting that it happened at all, but it was corrected without the loss of any VMs.

Virtual Iron Enterprise contains enterprise-level features such as VM snapshots, LiveMigrations, and LiveCapacity. LiveMigrations are the Virtual Iron equivalent of VMware's VMotion, where a VM is moved between physical hosts without requiring a reboot. LiveCapacity corresponds to VMware's Distributed Resource Scheduler, allowing the management server to make decisions on VM placement on a server farm to compensate for unbalanced loads. In practice, all of these functions worked nicely: LiveMigrations occurred quickly and without interrupting processes on the VM, and LiveCapacity adequately shuffled VMs around. In addition, there's nascent support for IPMI (Intelligent Platform Management Interface), providing some offline server maintenance capabilities.