– January 15, 2013
The OpenMirage project is seeking to become a Xen.org hosted project, as defined in the Xen Governance process. To become a Xen.org hosted project, a project proposal is needed that is first submitted for community review. The review is followed by a vote by eligible community members, which if successfull adds the project to the Xen.org incubator. The project can then graduate as outlined in the Xen Governance process.
I posted the proposal for community review on the xen mailing lists earlier this week: the community review is open 23:59 (GMT), 27th of Jan, 2013.
What is Open Mirage?
The following recording of a XenSummit presentation by Anil Madhavapeddy, the Mirage project lead, introduces the project, explains why it is relevant to Xen.org and concludes with some interesting benchmarks and discussion.
Posted in Announcements.
– December 31, 2012
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.
Posted in Community.
– December 24, 2012
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.
Posted in Community.
– December 18, 2012
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.
Posted in Announcements.
– December 17, 2012
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.
Posted in Xen Hypervisor.
– December 12, 2012
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.
Posted in Xen Hypervisor.
– November 27, 2012
Xen.org is happy to announce that XCP 1.6 has been released! The release is available from the download page:
New features and Improvements
XCP 1.6 has many new features and improvements, most notably Storage XenMotion, Live VDI Migration, improved integration with XenCenter, many Networking Enhancements including massive VLAN scalability improvements. Please read the release notes for details.
The following XenSummit video provides a good overview over XCP and also explains, how Storage XenMotion works.
Also see: Presentation
Information for XCP Beta Users
Note that the final XCP 1.6 build contains fixes to recent security vulnerabilities. This means, if you have tested the XCP 1.6 beta, you will need to upgrade from an earlier XCP beta install. Automatic upgrades from XCP 1.1 (as well as XCP 1.6 betas) are possible. Please consult the XCP 1.6 Release Notes for more information on upgrades and information on fixed security vulnerabilities.
Posted in XCP.
– November 23, 2012
The blkback/blkfront drivers developed by the original Xen team was lightweight and fast zero-copy protocol that has served well for many years. However, as the number of physical cores and the number of guests have increased on systems, we have begun to identify some bottlenecks to scalability. This prompted a recent improvement to the protocol, called “persistent grants”. This blog post will describe the original protocol and what the source of the bottlenecks are, and then will describe persistent grants, along with experiments demonstrating the scalability improvements.
How PV Driver protocol works
Xen PV drivers for block devices use a special protocol to transfer data from the guest to the devices that act as storage. This protocol is based on a shared ring that allows the exchange of data between the guest and the host. This ring is shared between the guest and the driver domain, which is usually Dom0. The driver domain has access to the physical hardware (a disk) or to the virtual image of the guest, and the guest issues requests to perform operations on this storage.
The capacity of the shared ring is limited, as also are the maximum number of requests in flight at a certain point. To avoid having to allocate a very large amounts of shared memory at start, Xen shared ring allocates at start only the minimum amount of memory to be able to queue the requests and responses (that is a single memory page), but not the data itself. The data is allocated using grants, which are memory areas shared on request, and references to those grants are passed along with the request, so the driver domain can map those areas of memory and perform the requested operations.
Posted in Xen Development.
– November 20, 2012
A couple of weeks ago I went to Copenhagen to attend Linaro Connect and Ubuntu Developer Summit for the first time. I was really impressed by the size of the conference, I wasn’t expecting so many people, it certainly rivals LinuxCon in terms of attendance.
All the best minds in the ARM world together in the same hotel for a week: the list of attendees includes Arnd Bergmann (Linaro), Olof Johansson (Google), Grant Likely (Linaro), David Rusling (Linaro), Jon Masters (Red Hat) and many others. You can imagine the level of technical discussions that was going on.
Posted in Events.
– October 31, 2012
In part 1 of this series, I introduced the concepts of full virtualization and paravirtualization (PV), as well as the hardware virtualization (HVM) feature used by Xen (among other things) to implement full virtualization. I also introduced the concept of installing paravirtualized drivers on a fully virtualized system.
This small step, from full virtualization towards paravirtualization, begins to hint at the idea of a spectrum of paravirtualization. In this article, I will cover the historical reasons for the development of PVHVM, and finally of the newest mode, PVH.
Problems with paravirtualization: AMD and x86-64
It comes as a surprise to many people that while 32-bit paravirtualized guests in Xen are faster than 32-bit fully virtualized guests, when running in 64-bit mode, paravirtualized guests can sometimes be slower than fully virtualized guests. This is due to some changes AMD made when designing the architecture which simplified things for them, but made things more difficult for Xen.
Most modern operating systems need just two levels of protection: user mode and kernel mode. Kernel mode memory is protected from user mode memory via the pagetable “supervisor mode” bit.
Posted in Uncategorized.