satis egitimisatis


Discussion on the state of cloud computing and open source software that helps build, manage, and deliver everything-as-a-service.

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that has been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Login
Tim Mackey

Tim Mackey

Tim Mackey is a corporate evangelist for XenServer within the Citrix Cloud Platforms Group and focused on server virtualization and cloud orchestration technical competencies.

Quite a few years ago I made a rather nice living coding things up. Some were big projects used in regulated industries, and others a bit more mundane, but in all cases I tried to ensure confusion over what the point of the project was could be minimized. After all, the last thing I wanted was a prospective user or partner investing in something which wouldn't meet their needs.

Fast-forward to today, and as the XenServer evangelist I want to accomplish the same task, but scope is a bit broader. I want people to be using XenServer, and I want many tens of thousands of them doing so. By the same token, I also want those same users to know they are using XenServer, and not something else. After all, its equally bad if someone thinks they're using XenServer when they aren't, or are using something different when they are in fact using XenServer.

A perfect case in point is the confusion over what "Xen" and "XenServer" are. For years I've heard people who want XenServer referring to it as "Xen" and occasionally as "Xen Server". While many of those people aren't technical, and for them the distinction is largely irrelevant, the fact of the matter is the distinction does matter. For example, if someone is working on a project which they wish to integrate with XenServer, it does them no good to see references to "Xen" all over XenServer content, or to look at examples which reference "Xen"; even if the actual code is for XenServer and not "Xen". Even more significant is that, with the move of the "Xen" hypervisor to the Linux Foundation last year, what was once known as the "Xen" hypervisor has now become the Xen Project hypervisor.

All of which gets me to Apache CloudStack. Apache CloudStack is a wonderful solution for anyone looking to get a cloud up and running quickly, particularly those looking to have multiple hypervisors in their cloud and managed from a single console. Unfortunately, Apache CloudStack is also a perfect example of the problem I'm highlighting here. Within the UI, documentation and code, the term "Xen" and "XenServer" are used interchangeably, when in reality Apache CloudStack only supports XenServer; or more precisely XAPI based toolstacks for the Xen Project hypervisor. To resolve this problem, and to pave the way for the Xen Project hypervisor to become a full citizen of Apache CloudStack, I put forth a proposal to distinguish and disambiguate "Xen" and "XenServer". The design document can be found on the CloudStack wiki. To give an example of the cost of resolving these things after the fact; the initial patch consisted of over 17,000 lines, subsequent patches will be needed following extensive testing, all with the result of no new functionality. If you're interested in following the progress of this activity, please do so on the CloudStack mailing lists, and on the wiki.

The point I hope I'm making here is that when there is the potential for confusion, someone will eventually become confused. If you are working on something which references "Xen" or "XenServer", I hope you'll take a few minutes to see if you're using the right references and if not plan on clarifying things for your customers and users. To assist, please refer to this handy-dandy list:

  • "Xen" is a bare metal hypervisor which since April 2013 is a Linux Foundation Collaborative Project and has been renamed as the "Xen Project hypervisor". You can find more information about Xen Project at Importantly, while "Xen" was the name Citrix used for the hypervisor, when "Xen" moved to the Linux Foundation, Citrix granted the Linux Foundation the limited rights to use the word "Xen" as part of the "Xen Project".
  • Citrix continues to use the "Xen" mark in connection with a variety of products such as XenApp and XenDesktop, so if you are working on a project with integration into other Citrix products, and are referring to them as "Xen", you risk further confusion with the hypervisor work occurring with both XenServer and the Xen Project.
  • XAPI, or XenAPI, is a toolstack for use with the Xen Project hypervisor and is a sub-project under Xen Project at the Linux Foundation. You can find more information about XAPI at
  • XenServer is a packaged virtualization solution from Citrix which in June 2013 was made completely open source. XenServer uses the Xen Project hypervisor and API support is provided via XAPI. Commercial support for XenServer is available from Citrix, and open source activities can be found on
  • XCP, or Xen Cloud Platform, was a previous attempt at making XenServer open-source. With XenServer becoming open source in June of 2013, XCP development transitioned to XenServer.       
Hits: 25879
Rate this blog entry:

It was the worst of times; it was the best of times. The opening paragraph to Dickens' A Tale of Two Cities describes a world not unlike our own, and in the years I've been working with technology, never has a quote applied more to a product I'm working on. The start of 2013 was our winter of despair. This was the time of XenServer 6.1, and a release that was in desperate need of attention. Performance, stability and overall capabilities were frequently called into question in forums, Twitter and in blogs. Almost daily there were cries of pain and claims of plans to migrate from XenServer. While I know some did migrate, migration isn't exactly painless so we had a chance to recover; but we needed to do the right things starting with two huge items:

  • Patch the product. It took a few months, but we finally got that right. As of the end of 2013 we're at patch 34, so it's not been an easy time, but XenDesktop customers can have every confidence a deployment on XenServer 6.1 as part of their product entitlement is a good choice.
  • Improve performance. For years it was possible to purchase a server that had more capacity to run VMs than XenServer was capable of running. In an attempt to resolve this we developed cool new architectures like Windsor, but after doing some heavy-duty performance analysis it was determined bottlenecks did exist, and that they could be resolved. So resolve them we did, with the result being an ability to run hundreds of VMs per host in XenServer 6.2.

We also realized that in the cloud era our users are interested in being in control of their IT in the way they deploy, purchase and integrate their infrastructure so we moved XenServer to an open source development model. An announcement doesn't make for a viable open source project and I was officially given the mandate to manage the community and evangelize the technology. Since most people starting a new position take stalk of where things are, that's what I did and the results weren't pretty. I found we hadn't completed posting source code and minimal communication was occurring on the lists; and while we're not great at it, we're getting better. I beat the drum consistently within the XenServer development team that we need to be more transparent and accountable. I would love to say that we've fully transitioned to an open source and transparent model, but still need to improve as we get more comfortable with an open development model for XenServer.

Hits: 19326
Rate this blog entry:
Continue reading Comments

On October 1st, 2103 I officially joined the Open@Citrix team as the XenServer Community Manager.  Since joining, I’ve been hard at work behind the scenes trying to ensure that our “XenServer is Open Source” effort from June is able to realize its full potential.  As you might expect, taking a product which was developed using closed source methodologies and mindsets and making it open source and transparent isn’t easy.  That source for portions of XenServer were already publically available did help, but there is considerably more to this than just putting some source files on GitHub and calling it a day.  Details like how transparent development relates to revenue recognition in a global public company, how closed source efforts which incorporate or embrace XenServer can continue without themselves becoming open source, ensuring all sources are posted and buildable, how EULA operates when you “upgrade” from an open source installation to a commercial license, creating a public bug database and project wiki, and how contributors engage with the project are all crucial; and not all that much fun. 

Of course it would be ideal if everything was live on Day 1, but that isn’t realistic.  XenServer has been under development as a Citrix product for over six years, and you can’t simply shift that inertia overnight.  The good news is that we are making progress, and you can follow that progress in my blogs.  I intend to post a status report for each month detailing what occurred in the previous month, good or bad, and that brings me to the type of community I hope we get.

This past year I’ve attended a number of open source, industry and vendor events.  Some were very developer focused, some community driven, some related to specific products, and others were populated by executives.  Each had its own vibe, and each was important to their respective community.  We’re not likely to ever have a “XenServer conference”, but we are likely to be at many conferences in one form or another.   At each event I attended, there was always at least one attendee who was enthusiastic about their use of XenServer.  They were proud with what they had accomplished using XenServer and wanted to share.  Some had experienced issues, and were happy to relate the problem, but also that they’d successfully found a solution.  These are the enthusiasts I want to form a cornerstone in the XenServer community.  I want them to encourage their vendors to support XenServer, and I want that same vendor eco-system to flourish around a solid base.  I’m also prepared to do what I can to facilitate just that.

Here is how I define the XenServer community:

The XenServer community is an independent group working to common purpose with a goal of leveraging each other to maximize the success of the community.  Members are proud to be associated with the community.

Hits: 14071
Rate this blog entry:
Continue reading Comments


Citrix supports the open source community via developer support and evangelism. We have a number of developers and evangelists that participate actively in the open source community in Apache Cloudstack, OpenStack, OpenDaylight, Xen Project and XenServer. We also conduct educational activities via the Build A Cloud events held all over the world.