Building VMs on XenEnterprise is simple but requires specific OS templates be present on the server itself for non-Windows VMs. When the Linux pack is installed, templates are presented for most major distributions from Red Hat and Suse, as well as for Debian Sarge. These templates are necessary because XenEnterprise relies on paravirtualization to run these VMs: They don't truly run in their own emulated server space. Windows guests are handled differently: It's possible to boot a Windows VM from a Windows Server 2003 install CD and build the VM from scratch.
Tripped up again
My first VM installation on XenEnterprise flushed out a few problems. I initially configured a new Red Hat Enterprise Linux 4 Update 4 VM with 1GB of RAM and an 8GB disk. Once I started the new VM and linked to the console, XenEnterprise's customized Red Hat Enterprise Linux 4 installer was already running. I ran through the familiar installer, opting to do the installation via NFS. When configuring the NFS mount to find the required installation packages, I inadvertently mapped to an NFS directory containing the x86_64 version of Red Hat Enterprise Linux 4 Update 4, not the i386 version. Rather than throwing an error, the management application and the server itself locked up tight, requiring a reboot. After that, I was able to build Red Hat Enterprise Linux 4 Update 4 and Windows Server 2003 VMs with no issues, as long as I was sure not to use 64-bit versions.
XenEnterprise doesn't claim to support 64-bit VMs, so the fact that they didn't run on the server wasn't a surprise. But the server locking up certainly was -- a warning dialog here is really mandatory.
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.
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.
Ease of use (25.0%)
Overall Score (100%)
|Virtual Iron Enterprise Edition 3.7.1||7.0||7.0||8.0||8.0||9.0|
|XenSource XenEnterprise 3.2||7.0||6.0||8.0||7.0||7.0|
Having trouble installing and setting up Win10? You aren’t alone. Here are many of the most common...
It's all about knowing how to build an open source community -- plus experience running applications in...
Win7 Update scans got you fuming? Here’s how to make the most of Microsoft’s 'magic' speed-up patch
Look to these clever open source tools to keep secrets out of source code, identify malicious files,...
From a simple platform for beginners to an expert-level development workbench, there's an IDE for most...
Technology may appear to be smart, but in most cases it merely has great logic. That’s not the same as...
Stop obsessing about the latest overhyped security threats. Delve into your own data about successful...