Citrix XenServer is tops among Xen-based hypervisors

XenServer’s hardware support was second only to that in Novell’s Xen implementation, which has a slight advantage because it runs on any hardware supported by the Novell SLES 10 Linux distribution.

XenServer's hardware support was second only to that in Novell's Xen implementation, which has a slight advantage because it runs on any hardware supported by the Novell SLES 10 Linux distribution.

XenServer's support for guest operating systems — the strongest such support among the Xen packages — includes: Windows Server 2000, 2003 and 2008 (32- or 64-bit), Windows Vista (32-bit), Windows XP SP2 or SP3; CentOS (versions 4.5 to 5.2); Red Hat Enterprise Linux (RHEL) (versions 3.6 to 5.2); SLES versions 9 and 10 (with various service packs); and Debian's sarge and etch releases.

XenServer installs Citrix's modified version of Linux with the Xen kernel, which requires a 64-bit processor. XenServer has a simple, text-based installation routine, the console for which is useful for most post-installation tasks. We tested both, and highly recommend using the bundled (it's included in the base price, a big plus) XenCenter hypervisor-management application on a connected Windows client machine. XenCenter’s templates ease the construction of new VMs tremendously. Citrix also lets the builder modify a blank template to support the installation of generic guest operating-system configurations.

We were frustrated by the fact that the templates didn't let us change the minimum storage values recommended by Citrix. For example, Citrix's edict is that Windows 2008 requires 24GB of storage; the only way to get around this was to delete the default/unchangeable virtual hard disk after we created it, then add another virtual hard disk with the custom storage size we desired.

XenCenter handled our ongoing management and monitoring jobs quite easily overall, but there were some minor caveats to our satisfaction.

Overall, the XenCenter interface was good, but it still lags a bit behind VMware's: Day-to-day process flows were more easily accomplished with VirtualCenter.

Setting up XenServer's VM monitoring facilities was very simple, because there is a list of monitored attributes (very similar to the set offered by VMware) including CPU, network usage, disk space usage, memory usage, number of CPUs per VM, hard-disk size and IP-address traffic volume. You merely have to check off what you want monitored.

XenCenter's alarms are called alerts. We could set thresholds for anything we could monitor. If a VM reached above a certain percentage — for memory use, for example — for a set number of minutes, XenCenter would correctly trigger the alert. We also could monitor alerts manually via the GUI, under the Logs tab of each server where they're identified by the color red. The logs also rendered a detailed listing of recent events from VMs on that server.

It's possible to have alerts based on preset trigger conditions e-mailed to you (although we couldn't get that working correctly with our mail server). Mail options are frustratingly limited.

We did find some minor issues when we were moving stored VM images created under XenServer. For example, when we wanted to move a stored VM image file from local storage to shared storage on the same host machine, we had to copy the VM, then select the option to delete the original VM. This process had the undesired effect of changing the VM's Ethernet media access control (MAC) address on its network card, and you then had to change it back manually. This is not a huge issue, but it's a step that XenCenter should have taken care of for us.

Also, we couldn't copy a VM from the local storage on one machine directly to local storage on another machine. We had to put the VM into shared storage, then copy it again, an inconvenient two-step process.

We could copy or move only one VM at a time, but multiple VM-movement jobs could be queued and duly handled in turn.

Citrix's bundled XenServer has no built-in security support beyond simple password access. Because it's not policy-hardened, the password is vulnerable to dictionary attack. In addition, there is only one user — a root user, so that user can do anything, including disrupting or destroying working VMs.

Migration and consolidation patterns

XenServer uses resource pools to allow VMs to be migrated rapidly between hosts. These resource pools aggregate VM machines and resources into objects that can be manipulated as grouped-together members of the same unit.

We found strong vendor stipulations on how these work. According to XenServer's documentation, cross-hypervisor server migration is possible when "each CPU is from the same vendor (in particular, AMD-V and Intel VT CPUs cannot be mixed), each CPU is the same model (except for stepping), each CPU has the same feature flags, [and] all hosts are running the same version of XenServer software." These constraints make migrating VMs more difficult in an environment that lacks identical hardware, and certainly more onerous than any other restrictions put in place by other hypervisor vendors.

Citrix also offers a XenServer Live Migration, which is the ability to move a VM from one host to another without the VMs losing (much) availability. As long as we stuck with VMs in the same resource pool, this feature worked well. Migration was fairly quick, removing active VM availability for only a few seconds at most.

VM snapshots, while missing from the GUI, are available via the command line. Snapshots in XenServer don't seem to work in the same way that other hypervisors' VM snapshots do. XenServer's snapshot process just creates a template for the VM. With other vendors' snapshots, we created a kind of hierarchy of iterative snapshot files and reverted to any point in the hierarchy to capture the desired time-stamped snapshot.

Consolidation require P2V tools

A physical-to-virtual (P2V) maneuver takes a working server's operating system, applications and stored data, and converts it to a VM without anything having to be reinstalled from scratch on the virtualized host system. P2V is a useful and necessary process for corporations looking to virtualize existing data center servers — whether they are Windows or Linux ones. Without P2V tools, building a VM entails installing the server operating system, then installing applications, then migrating the existing data to the new host.

Citrix offers separate P2V utilities for Linux and Windows servers. XenServer's Linux P2V application is included on the XenServer installation CD. You must boot from the machine using this CD if you want to convert a physical Linux machine to a VM.

We had issues with this tool during testing. Our server was running SLES 10.2, but the Citrix utility couldn't detect the operating system on that server. We were able to start a P2V of an SLES 9 32-bit installation, (although it mistakenly identified it as Red Hat 3) but it failed with a generic failure error 500. We tried again with an AMD64 machine with Ubuntu running on it, but the application still showed no supported operating systems and wouldn't let us proceed with making a P2V of the Ubuntu image.

The second Citrix P2V utility is called XenConvert on Windows, which takes a Windows operating system and its applications, then turns the combination into a VHD or XVA file to import to XenServer to run as a VM. That said, the process failed with one Windows XP machine in the test bed. XenConvert consistently gave us an error message each time we attempted the process. A second Windows XP test machine could be converted, but the boot loader (grub) was mangled and the new XP guest instance wouldn't load. We had to fix the grub configuration to make it work.

XenConvert may work for versions of Windows and Linux we did not test, but we were certainly dismayed at the lack of success in testing.

< Return to main test: Citrix, Novell make a valid run at VMWare ESX virtualization crown >