Once I had several VMs running on the server, I brought the iSCSI SAN into the fray. I quickly discovered that there's no way to do this via the management application, as all disk management occurs at the command line. I'm no stranger to the open-iSCSI toolset, so I quickly configured the server to map a LUN from the NetApp StoreVault and presented it to the OS as a new device. That's when things got a little interesting. After some research on XenSource's forums, I found the back-end commands required to present that volume to the Xen service and rebooted the server. Much to my surprise, my local disk store was replaced with the new disk store, leaving my VMs without any disk. However, I could create new VMs with their virtual disks residing on the SAN array. Suffice it to say that this basic iSCSI support will be fine for those well versed in Linux and iSCSI, but largely insurmountable for those without this experience.

Click for larger view.

Sticking with local disk, I ran performance tests on the VMs running under XenEnterprise. I found that the paravirtualized Linux VMs ran remarkably well and didn't buckle under extreme stress. The Windows servers didn't perform quite as well, but they were certainly responsive and capable of supporting a reasonably heavy workload.

The Linux VMs do not require separate management tools, as with VMware or Virtual Iron, but the Windows VMs do, since they're not paravirtualized. These tools are installed much like VMware Tools, via an ISO image presented to the VM as a CD-ROM drive. They provide a few new drivers and some host-guest communications.

The performance monitoring in XenEnterprise is presented in the management app window with graphs representing the host server's workload as well as the workloads of individual VMs, but it lacks granularity. You can definitely get a good feel for when a host or VM is working too hard, and track some trends, but that's about it. Also, I occasionally lost keyboard access to the VM consoles, a problem that could be rectified by popping the console window out of the main app window and back again a few times. Like Virtual Iron, console access is based loosely on VNC (virtual network computing), though I have to say that the mouse tracking with Windows VMs in XenEnterprise was better than in Virtual Iron.

Two on the cheap
XenEnterprise and Virtual Iron Enterprise have a long way to go to provide the same level of stability, features, and performance found in VMware Infrastructure, but VMware's tail lights are in sight. I found myself liking both of these Xen-based packages, and I could certainly see myself building out a virtualized environment on either platform. However, I couldn't see that being a possibility for someone without a solid Linux background, especially with XenSource.

Virtual Iron is clearly out in front of XenSource, thanks to support for physical server farming, VM migrations, load balancing, and easily managed iSCSI and Fibre Channel SAN connectivity. Nevertheless, if XenSource makes good on its promises, XenEnterprise will have these features ready later this year.

I'm left with the feeling that VMware better not sit on its laurels. These two products are on their way to providing truly enterprise-grade virtualization foundations for a mere fraction of VMware's licensing fees.