This is a guest blog post by George Boutsioukis, one of our Google Summer of Code students.
My name is George Boutsioukis and I’m a CS undergraduate at the Aristotle University in Thessaloniki, Greece. This is my second year in GSoC, after taking up a project last year for Python. Coming from a background mostly in compilers and machine learning, this project for me is also a crash course in virtualization and Xen.
My project is to implement paravirtualized audio in Xen, following in principle the split-driver approach already used in the other PV drivers so far. Compared to network and block paravirtualization, audio interfaces are relatively simpler to support (at least for PCM). A backend driver would only need to transfer and play the raw audio frames of the PV guest directly, without any need to process them. However, there are a few issues that need to be dealt with, most notably buffering/synchronization problems and the performance overhead it may introduce.
The initial approach is to make both ends run in userspace, using gntalloc for this purpose. A pulseaudio sink module at the frontend will transfer the raw audio frames from the guest to a backend daemon through a ring buffer. Audio capture should work in much the same way, only in reverse. The transferred data are not pulseaudio-specific, so this approach can be extended (in theory at least) for any frontend interface that works with raw PCM data, like ALSA for example.
Fortunately, some work has already been done in this direction: Rafal Wojtczuk has already written a basic PV audio implementation for Qubes-OS, which will be used as a guide for the first steps of this project. Of course, the goal is to make the final implementation production-ready, so I expect a large part of this project to be spent on dealing with practical issues, like receiving audio from multiple frontends or dealing with suspending/resuming a guest.
The code and any other relevant files will lie in a public repository at code.google.com/p/xen-audio for anyone who wishes to follow the project during the summer. The code will be upstreamed to Xen when the project is complete.
You may remember the Community vote on the Xen Governance Proposal: well the deadline for the vote passed a few minutes ago and I closed the vote. There was almost unanimous for the proposal:
- 92% in favor
- 8% abstained
I also got some constructive and encouraging feedback such as:
- I strongly agree with all of the points outlined in this proposal. The controls outlined should bring transparency to the process of Xen development whilst not endangering the current unwritten code.
- Good proposal, but could benefit from defining the role of the sponsor and mentor better and by clarifying their role during phases in the project lifecycle.
- Clarify the scope of voting, i.e. when are votes local to a project and when not
As next step, I will update the document, share it and I will start engaging with project leads to agree how to migrate to their projects to the new process. Following that, the xen.org site structure will be changed around the concepts of mature, active and archived projects.
My name is Mike McClurg, and I am a Citrix developer working on the Xen API (xapi) and the Xen Cloud Platform. I have recently been chosen as the new lead for the XCP project, and there are a few exciting new developments that I’d like to share with you.
As you may have heard, both Citrix and Canonical have recently announced their support for OpenStack, an open source cloud controller sponsored by Rackspace and NASA. In order to make the Xen API toolstack the best solution for running OpenStack on the Xen platform, we’ve decided to port XCP’s Xen API toolstack to Ubuntu. This would allow you to do ‘apt-get install xapi’, and effectively turn your Ubuntu machine into a Xen Cloud Platform server.
As part of this project, we aim to move XCP to a fully open development process that will allow much greater participation from the Xen community. Building individual toolstack components will no longer require an SDK environment. XCP source repositories will be updated more frequently. Releases of the monolithic, CentOS-based XCP appliance will become more frequent as well.
With the recent announcement of full Xen dom0/domU support in Linux 3.0, and the Xen API toolstack moving to support Ubuntu and other distributions, this is a really exciting time to be a part of Xen.
This is a very short blog post as both Wim Coekaert and Ewan Mellor beat me by some time in publishing this great news: I was too busy traveling and celebrating. The fantastic news is that Linux 3.0 will have everything necessary to run Xen as both as a management domain and as a Xen guest. You can find more information in the following two posts
A big thank you to everybody in the community who helped make this happen. To conclude let me quote from Wim’s blog post, as it captures really well what this means for our community!
“All this means that every single bit of support needed in Linux to work perfectly well with Xen is -in- the mainline kernel tree. I’ve heard over the last few years, competitors use “There is no Xen support in Linux” as a tagline to create fud with the Xen userbase and promote alternatives. Well, it’s all there people. As Linux evolves, now, within that code base, the Linux/Xen bits will evolve at the same rate without separate patch trees and big chunks of code to carry along. This is great, Xen is a great hypervisor with capabilities and features that one cannot achieve in a non-true hypervisor architecture.“