Playing around with Citrix XenServer

I recently had the pleasure of playing around with Citrix XenServer/XenCenter. I tried to mimic another setup based upon VMware to compare features and see whether we could use XenServer instead of V Mware. Although it might not be a fair comparison since VMware is at least 2-3 times more expensive, I have become a bit spoiled with VMware’s enterprise features and expect the competition to provide the same features.  Anyways, since XenServer 6.0 is just out, it was about time to take another look at it.

Citrix XenServer/XenCenter does a lot of things right. For a development cluster, it would probably be the right product if licensing is a major factor. However, I am more reluctant to use it in a production environment due to the issues listed below (also known as the bad stuff):

The Bad Stuff

Lack of redundancy and separation of management traffic:

• There is no support for a bonded management interface in combination with resource pools. If you create a new bonding pair and put the management interface on that interface, it will work, but you will run into serious trouble when you try to add another host to the cluster. I ended up with one host that was member of several clusters at the same time and no way to remove it from the original one. This means that the management link is non-redundant.
• Lack of VLAN support for management: You cannot use VLANs to separate management traffic from for instance “VMotion” traffic that goes over the same physical interface.

Not a fully integrated solution:

• XenCenter requires a physical host with Windows (or potentially Linux).  There is no central database, everything is configured and stored on the clients.
• Every enterprise feature you add is a VM. Want WLB (WorkLoad Balancing), the Citrix equivalent of DRS? Add a VM. Want licensing? Either install another package on your Windows host or install another VM. Want DvSwitch support? Install yet another VM. Self-Service portal? Another VM. All of these VMs requires another IP, some passwords and some configuration.
• WLB has to be suspended during upgrades. HA has to be completely disabled.
• Upgrades or patches means that you have to upgrade all hosts at the same time.
• Catch 22: To upgrade a host, you have to upgrade the pool master. To upgrade it, you have to put it in maintenance mode, something you cannot do since it is the pool master. The solution is to use the upgrade/patch guide embedded in XenCenter.

Storage support:

• Thin provisioning is only supported on NFS or through the use of storage plugins. This means that with regular iSCSI, you cannot thin provision your guests.

Resource management:

• VMware has the following options for reducing the memory footprint of a VM: Ballooning, swapping, memory compression and page sharing. XenServer can only do ballooning.
• Resource sharing is based upon statically configured values on each VM. There are no equivalent to VMware’s resource pools, meaning that you have to spend some time to configure your cluster every time you add another VM.
• No storage DRS. However, the WLB will take disk usage into account when rebalancing the cluster.

Virtual machines:

• Every virtual machine has to be deployed from a template
• The templates are heavily restricted: RHEL5 only supports 16GB of memory, RHEL6 supports only 32GB.
• PXE boot is considered a special feature, only a few templates can do it. The other templates need HTTP support or CDs/disks.
• You need a custom Xen kernel to use the Xen tools.
• To do memory ballooning, you need the Xen tools installed.
• If you deployed your virtual machine from the wrong template, it will have the VT bit exposed. Having the VT bit exposed in the VM makes the tools go nuts and refuse to operate.

Now to the things that I actually like:

• XenCenter is really lightweight and fast.
• The basic features are working: You can run multiple operating systems (with a few restrictions), HA works and WLB will place VMs on hosts that have spare capacity.
• Maintenance mode works
• As long as you turn off HA/WLB and provide a web repository, the automatic upgrade feature works.
• In a basic setup it will give you more bang for the buck.
• You can edit host settings on a cluster basis. Adding a VLAN to a VM uplink on cluster level means that it is automatically added to all hosts. The same applies to storage devices as well.

Conclusion

Citrix XenServer will probably be the right commercial solution for a lab setup unless you already have a VMware based environment. However, I am very reluctant to use it in an enterprise, 24/7 environment. Lack of automatic resource sharing, memory compression/swapping and resource management based upon pools instead of per-VM configuration makes the management overhead a bit high and will probably mean that you have to add additional hosts to the cluster to get the same performance as VMware.

Reading through the documentation also gives me a feeling of an unfinished product: a lot of stuff is configured command line on each host. A finished enterprise product should, IMHO, not require that the users has extensive knowledge of inner workings of a product. The GUI should take care of at least 90% of the tasks, and it should cover all the tasks carried out on a day-to-day basis.

Judging by the feature set, Citrix and the rest of the Xen community is copying all of VMware’s features instead of making their own, unique features. This is not necessarily a bad deal, but you have to to it as good as or better than the original to compete. This is not the case – I am left with a feeling that on a number of areas, nothing has happened since I tried out Virtual Iron in 2009. Virtual Iron almost got it right, but VMware have addded a lot of features since then.