WoodITWork.com

Citrix has released a Beta of their next major XenServer version called “Project Boston”.
http://community.citrix.com/pages/viewpage.action?pageId=173115376

Some highlights from the new version release notes that I’ve spotted other than the expected performance enhancements are:

• The Open vSwitch (OVS) which is a distributed virtual switch is now the default network stack for the product. I haven’t used the OVS with XenServer 5.6 FP1 as FP1 isn’t supported with XenDesktop and I like the simplicity of standard switches so will have to reserve judgement on whether the additional complexity is worth it.

• Workload Balancer will now be a virtual appliance rather than having to be  installed on a Windows Server. This is a step in the right direction as with 5.6 you have to have a windows server and associated database per pool to manage WLB and store historical performance reports. I would actually prefer the functions of WLB and historical reporting be split and WLB to be a pool maintained function and not require any management infrastructure.  The obvious comparison is with VMware DRS which does require vCenter to manage it but doesn’t require a separate management server/appliance per cluster. Historical reporting should then be a separate function to be pumped into a database either on the appliance or remotely where you can also report on performance across multiple pools.

• Self-Service Manager is XenServer moving towards the private cloud by providing a way to create VMs from a “Service Catalog” and interestingly will work with vSphere. Not quite sure how this will work across hypervisors.

• VMDK import is already integrated into XenCenter so not sure what more is coming. Would be great to be able to do a XenConvert directly from XenCenter without having to launch a separate application.

• Microsoft System Center integration is a great addition for Microsoft shops. Management and monitoring of XenServer is currently a weak point so SCOM/SCVMM functionality would help. Not sure what you would be able to do if you don’t have System Center as currently XenServer’s monitoring is severely lacking.

• HA support for NFS is great. Requiring an iSCSI LUN when all your VMs are running off NFS is painful! Go even better though and make HA a self maintained pool function and not require any additional storage.

• Nic bonding reliability enhancements and support for active/passive bonding are both steps towards better converged networking.

I haven’t had a chance to try the Beta yet but here’s a quick XenServer wish list…maybe some things are already there:

• Multiple pool management. It’s great not having any single point of failure for a XenServer pool particularly with VDI as is the case with vCenter but VDI means massive scale which generally means more than 1 x XenServer  pool.  Having such segregated pools makes it far harder to manage your environment so I would love to see the following:
  • Be able to share templates between pools.
  • Be able to have storage repositories visible in multiple pools to enable far simpler VM migration between pools.
  • OK, let’s go one step further and allow XenMotion of VMs between pools.

• Support the Management interface working on a VLAN, There is no reason why this shouldn’t be done. With blade servers and converged networking, VLANs are the way to go and having to resort to a separate management network or native VLAN config is from the dark ages.

• Be able to properly segregate network traffic. XenServer needs to be able to direct storage/VM/management traffic over particular bonds and even particular Nics within a bond like with vSphere Port Groups. Current storage networking segregation requires your storage to be on a subnet non-routable from the management network which doesn’t cut it in a converged networking world.

• More than 1 XenMotion at a time…obvious.

• Better pool networking availability. One of the major issues with XenServer is when there is a network issue, the XenServer pool masters can lose network connectivity and don’t recover easily which disconnects the entire pool and requires you to manually emergency reset the pool master and often reboot which takes a long time…while your VDI clients can’t connect. All hosts should always remain on the network whatever problem there may be.

• Further enhancements to memory management. TPS would be nice.

• Better command line syntax, avoiding the need for so many long UUIDs. Having to read and type a UUID on a console session of painful, there should be a way to reference the UUID with a friendly name.

• More Powershell enhancements

I’m all for further innovation with hypervisors. The more competition thrown at VMware will push it to innovate even further which is good for everyone.