It’s almost 2013! Time to complete our review of 2012. In the first part of this article, we looked at the progress the Xen community made in terms of Governance, Community Diversity, Event Presence and covered cool Xen features that will land in 2013. In this article we will look at some negatives, a review of community initiatives and Xen and BSD/Linux. We will conclude with a brief outlook for 2013.
Despite all the progress, we struggled in some areas. For example, we should have had a new web platform and website by now. In spring we started a project to develop a new xen.org website and lost the developer half way through. For the remainder of the year, I didn’t have the bandwidth to pick up this project and get it finished. I simply underestimated the effort that is required to deliver a new website of that size. On the plus side, we have a vacancy for a Xen Evangelist that I hope will be filled shortly. With the help of the new Evangelist, it should be possible to complete the web site as well as do more community work.
It is the time of the year, when it is worth looking back and assess how we have done. For me, 2012 has been an exciting year with many positive changes in the Xen community. Not everything, I wanted to achieve has been achieved, but all in all we managed to make excellent progress in many areas.
Better Governance: The Road to more Diversity
We have come a long way in terms of governance in the Xen community. Looking back to early 2011, when I started as Xen Community Manager, the developer community largely operated through a set of unwritten rules. This made it hard to join the community as a developer, and may have put off some vendors. Since then we defined our governance model, which formalized values, roles, decision making, the project life-cycle and other areas. A consequence of this was that ownership and responsibilities of tasks have been distributed to community members. We tested the process by archiving old projects such as XCI and through the security vulnerability response process discussion (which still needs to be closed). We also created a forum for distinguished community members (individuals as well as vendors contributing to the project) through the Xen Maintainer, Committer and Developer Meetings, whose main purpose is to solve common goods questions, longer term evolution of Xen and to do more up-front planning. Also, we have a better approach to planning and generating a Xen Roadmap, thanks to George Dunlap who has stepped up as Xen Release Manager for Xen 4.3.
I am pleased to announce the release of Xen 4.2.1 and Xen 4.1.4. These are available immediately from the following locations
We recommend that all users of Xen 4.2.0 upgrade to Xen 4.2.1 and that users of the 4.0 and 4.1 stable series upgrade to Xen 4.1.4.
After concluding our poll about changes to the security discussion, we determined that “Pre-disclosure to software vendors and a wide set of users” was probably the best fit for the community. A set of concrete changes to the policy have now been discussed on xen-devel (here and here), and we seem to have converged on something everyone finds acceptable.
We are now presenting these changes for public review. The purpose of this review process is to allow feedback on the text which will be voted on, in accordance to the Xen.org governance procedure. Our plan is to leave this up for review until the third week in January. Any substantial updates will be mentioned on the blog and will extend the review time.
All feedback and discussion should happen in public on the xen-devel mailing list. If you have any suggestions for how to improve the proposal, please e-mail the list, and cc George Dunlap (george dot dunlap at citrix.com).
Read on for a summary of the updates, as well as links to the full text of the original and proposed new policies.
The “Normal” Case
To explain what is a Stub-Domain (often called stubdom), let’s start with the basics. When you start a new guest with Xen, you would need a Device Model which does some emulation if the guest does not have PV drivers. This is the case for an HVM domain.
This device model (which is QEMU), needs to run somewhere. By default it runs in the Dom0, as root.
Here is a picture:
Now, every time the guest do an IO, like reading a file on the disk, there is an event sends through Xen to the device model. It does the emulation and send the result to the guest.