Prior to the recent RTW release of XenServer 6.0, I’d been evaluating the Boston beta code in our lab. It’s since been updated to the GA code, which is what I’ll base my comments on. Overall, XenServer 6.0 seems to be a significant step in the right direction for the product. It’s definitely looking to position itself well for supporting and enabling Citrix’s cloud building products, and for moving up and right in the industry magic quadrants by increasing feature parity and performance equity with its competition.
Here’s what I like in the new version:
1. The underpinnings of XenServer 6.0 are based on the open source Xen 4 hypervisor.
2. In line with keeping to successful aspects of it’s open source heritage, the Open vSwitch becomes the default network stack for XenServer 6.0. We were impressed with its capabilities and the ability to provide true distributed networking features, security, and support for NetFlow. This looks to be promising for conformity to the OpenFlow standards that is important to cloud builders and cloud providers. I also like that if you prefer, the old-school Linux network stack (bridging) is still available as an option.
3. The rolling pool upgrade wizard is a nice feature to have. I have not fully tested this, but it looks like it should save some time and confusion when upgrading XenServer pools automagically.
4. Improvements to host and guest limits, better performance for XenMotion and a new version of XenConvert, which appears to be a bit speedier than it’s predecessors…
The only thing so far that I have come to dislike is not actually anything with the hypervisor. Rather, it is the fact that the paravirtualization tools (XenServer Tools) are dependent on .Net 4.0 to install properly on a Windows guest. For many this will not be an issue, but for others, like my current company, it is a major issue and a major obstacle in our overall hypervisor strategy that has left us in a predicament. We fought long and hard to get XenServer into our production reference architecture for our managed hosting business – the thought was to take advantage of a single-vendor, co-developed ecosystem (XenServer-XenApp-Provisioning Services-XenDesktop). Many of the applications we host have proven incompatibilities with anything but specific versions of .Net frameworks, and to make matters worse, .Net 4.0 framework actually is documented and known to break certain pieces of XenApp infrastructure! In summary, our architecture is now hanging in the balance and seemingly for the near future, orphaned at XenServer 5.6. The VMWare architects are all saying “I told you so – our vSphere PV tools have no .Net requirement “, and we are scrambling for a strategy to deal with this (we have engaged Citrix on this and are awaiting their response). The biggest problems I see with this are:
1. I can’t plan to use XenServer as my hypervisor for my provisioned XenApp workloads or any XenApp servers on which I have an application to publish that is incompatible with .Net 4.0.
2. My applications (healthcare applications) are not easily recompiled to be natively .Net 4.0 capable. Some can’t do 3.5 either, which is the only alternative I have found to work. They simply will not coexist with varying versions of .Net 4.0.
3. Because of #2, I cannot utilize VM Hosted Applications or virtual desktops on XenServer as a means by which I can deploy an application because the underlying or native VM will still require XenTools and thus .Net 4.0.
This is as much a Microsoft problem qnd an application development problem as it is a problem for virtualization engineers and architects. However, because many of us rely on XenApp to be the de facto platform for delivering legacy apps and the apps that don’t play well with others, it presents itself as something we do need to consider if putting on XenServer 6.0. While this is a conundrum for us, I think that in a way it’s good in that it has forced us to look at our applications and do our best to promote development for virtualization and 64-bit capability which will inherently bring things more current. It will also open up opportunities for us to move ahead with gain momentum with some new technologies that we’ve not focused on as much as we have with XenApp: App-DNA, App-V and Citrix Streaming, XenDesktop and VDI-in-a-box, etc. In the end, XenServer still provides cost savings and equal or better performance, as well as a single-vendor ecosystem for much of our technology offerings, particularly our managed services/hosting offerings.