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.