XenEnterprise 3.0 is the easiest to use and most manageable Xen virtualization solution eWEEK Labs has tested: Installing XenEnterprise was a snap, and it was easy to control multiple XenEnterprise servers from one place using the products Java-based administration console. Also, because a XenEnterprise installation completely takes over the machine on which it runs, we didnt have to worry about caring for a host system.
However, Xen is a rather young technology, and anyone whos surveyed the current field of Xen implementations knows that besting them is leaping a fairly low hurdle. While XenSource has certainly gone a long way toward making Xen a viable option for enterprises, its going to take more work before XenEnterprise will match up well with the offerings of commodity virtualizations heaviest hitter, VMware.
In this initial version (despite the 3.0 version number), XenEnterprise is limited to creating guest instances running Debian GNU/Linux 3.1 or Red Hat Enterprise Linux 4.1. XenEnterprise can also convert instances of RHEL 4.1, RHEL 3.6 and SUSE Linux Enterprise Server 9 Service Pack 2 into Xen virtual machines using a tool that ships on the products installation disk.
While XenSource still has a lot of work ahead of it, XenEnterprise 3.0 is a solid product thats certainly worthy of further evaluation at shops that run Debian, RHEL or SLES servers, and that wish to keep tabs on all of their virtualization options. Administrators who are interested in learning more should download the free, 30-day trial version of XenEnterprise 3.0 here.
XenEnterprise 3.0 pricing is a fairly complex affair thats based on number of physical servers, number of sockets per server and whether customers are looking for perpetual or annual subscription pricing. An annual subscription for one two-socket server is $488, and an annual subscription for a 32-socket server is $7,800. In comparison, VMwares ESX Server ranges from $1,000 to $5,750 per pair of processors, and VMware Server, which is capped at two processors, is freely available.
Guest OS limitations
The biggest gap right now between VMware and XenEnterprise is in the breadth of guest operating systems supported and the tools available for creating new guest instances. The challenges for XenEnterprise on both fronts stem from the fundamentally different ways that Xen and VMware technologies relate to the guest operating system instances they host.
VMware products offer up virtualized machines that work pretty much the same as physical machines. Installing an operating system on a VMware guest is as easy as booting from the operating system install disk and proceeding normally—the BIOS of the virtual machine hands control over to the boot manager of the install disk, which hands control off to the kernel of the installer disk or to the kernel of the already-installed operating system.
Xen doesnt virtualize the pre-boot environment in which operating system installers are accustomed to operating, so new Xen installations must either depend upon the availability of alternative installer tools capable of installing an operating system into an arbitrary location or clone an already installed system.
Also, Xen instances currently require a modified kernel to run. Since most Linux distributions (particularly enterprise distributions) dont yet ship with Xen-enabled kernels by default, XenSource must provide the kernels, further limiting the range of distributions currently supported.
Debian GNU/Linux offers a very good tool—debootstrap—for performing installations, and, not surprisingly, Debian installations on XenEnterprise 3.0 run rather quickly and smoothly. From XenEnterprises administration console, we needed only to input a name, choose an amount of RAM to allocate and hit install. We installed XenEnterprise on two Advanced Micro Devices Opteron-powered servers—one single-processor system and one dual-processor system. On our SMP host, we also could choose how many CPUs to make available to our Debian guest.
In a little more than 2 minutes, our new Debian system was booted and asking for a root password, which we provided through a text console window in the XenEnterprise administration console. Our new Debian installation also requested a password for its preinstalled VNC (Virtual Network Computing) remote control application, through which we could interact graphically with our new system (also from the XenEnterprise administration console).
During testing with RHEL installations, XenEnterprise asked the same initial questions as it did for new Debian installs, and then booted us into RHELs network installer.
RHEL 5 will be the first RHEL version to ship with built-in Xen virtualization support, and we hope that RHEL will become more Xen-installation-friendly as a result.
The XenEnterprise installation path for SLES 9 is the least smooth, as it requires the XenEnterprise physical-to-virtual conversion tool (available on XenEnterprises distribution disk). However, once we installed a Xen virtual machine, we could clone it easily from within the XenEnterprise administration console.
What wed most like to see from XenSource is a tool that can handle arbitrary Linux distribution installations—something similar (if not in method, then at least in results) to whats possible with VMware applications. Were also looking forward to seeing XenSource make good on the promise it makes on its Web site—to support Windows and Solaris clients. According to XenSource officials, an early-access version of XenEnterprise with support for Windows should ship later this year.
We also would like to see XenSource provide template-building tools. While the template-based installation approach that XenEnterprise offers for Debian is rather handy, wed like to be able to modify the Debian template to exclude, for example, the GUI thats installed by default.
We did appreciate the XenEnterprise administration console. The console ran well for us both on Windows and on Linux, and it offered us easy access to each of the XenEnterprise hosts and guests that we had installed.
The administration console also provided us with some basic statistics on CPU, disk, network and RAM usage on our host and guest machines, but we would have liked to have more granular control over these resources. For example, it would be useful to be able to parcel out CPU and I/O caps among our guests.