As many of you might have (inevitably) noticed, Xen frontend / backend network drivers in Linux suffered from regression several months back after the XSA-39 fix (various reports here, here and here). Fortunately that’s now fixed (see the most important patch of that series) and the back-porting process to stable kernels is on-going. Now that we’ve put everything back into stable-ish state, it’s time to look into the future to prepare Xen network drivers for the next stage. I mainly work on Linux drivers, but some of the backend improvements ideas should benefit all frontends.
The goal is to improve network performance and scalability without giving up the advanced security feature Xen offers. Just to name a few items:
Split event channels: In the old network drivers there’s only one event channel between frontend and backend. That event channel is used by frontend to do TX notification and RX buffer allocation notification to backend. It is also used by backend to do TX completion and RX notification to frontend. So this is definitely not ideal as TX and RX interferes with each other. So with a little change to the protocol we can split TX and RX notifications into two event channels. This work is now in David Miller’s tree (patch for backend, frontend and document).
Xen 4.3.0 time is approaching and, to make sure we’re delivering the best possible release, we are having another Xen TestDay on Friday, June 28 2013. (RSVP and iCal here).
We will be testing Xen
4.3.0-RC6, that will be tagged on Thursday. It will ship two really important changes (as compared to RC5) about PCI passthrough and CPU hotplug. Help us making sure there are no issues left, both on those two specifically, and in general!
In fact, about the former, we’ve had to change the way Xen handles some aspects of PCI passthrough, to work around an issue with qemu-xen. We think we’ve got everything right, but please test your own configuration to make sure that it still works for you. We particularly need graphics cards with large amounts of video RAM tested. About the latter, CPU hotplug support was missing in qemu-xen, and it has now been implemented, so go ahead testing it (CPU hot-unplug is still not supported, though).
We will announce on the xen-devel (and other relevant) mailing lists when RC6 will become available. In the meanwhile, here they are the Xen 4.3 RC6 test instructions, while more information about Xen TestDays are available here.
Join us on Friday on the #xentest channel on freenode!
If nothing relevant comes up during the TestDay, the plan is to have the release next week, probably on July 2nd.
Today, Citrix announced that XenServer would be fully open sourced and that it will be made available from XenServer.org. First, I wanted to remind everyone that XenServer always has been based on open source software: containing the Xen hypervisor, the Linux kernel, the CentOS Linux distribution and user tools. However many XenServer components were proprietary.
In 2009, Citrix released XAPI – the XenServer management toolstack – and the XCP ISOs – a variant of XenServer that predominantly contains open source components – under open source licenses on xen.org. This marked the beginning of XenServer’s transition towards open source. In 2011, XAPI packages were delivered into Debian and Ubuntu, enabling users to build a XenServer like system from individual packages. Earlier this year, XAPI moved with Xen.org under the auspices of the Xen Project – a Linux Foundation Collaborative Project. In other words, the XAPI project is now a sub-project of the Xen Project. The creation of XenServer.org as announced today concludes this journey towards open source.
Why is this good for our community?
One of the consequences of open sourcing XenServer components (aka XAPI) and XCP in stages was that it created confusion amongst developers and users. This was compounded because some software – such as the XCP build system – was not available as open source. The primary reason for this is that the source code, project and the packaging (XCP ISO and XAPI packages delivered into Linux distributions) were not cleanly defined.
The Xen4CentOS6 project is a collaborative effort between the Xen Project, the Citrix Xen development teams, the CentOS Project team, GoDaddy Cloud operations group and RackSpace Hosting to package, deliver and maintain a stable Xen hypervisor and its related tooling for CentOS-6, enabling CentOS-6/x86_64 to be used as a dom0, base platform to host Xen in paravirt and fullvirt deployment roles.
We have tried to ensure that existing tooling that users have in production written again xm/xend will continue to work, while also adding support for the newer xenlight (xl) layers. Most libvirt functions also continue to work on Xen4CentOS6 as they did on Xen3 CentOS5, enabling users to easily migrate their infra over from CentOS-5 to 6.
A second primary principle we are working against is to build and deliver a Linux Kernel based on the 3.4 LTS release, stabilised via testing, with enhanced Xen support as recommended by the Xen development team.
Last week the proposed changes to the security policy were approved unanimously by the Xen committers; the policy has been updated accordingly.
What this means is that now if you are “public hosting provider”, “vendor of Xen-based system”, or a “distributor of operating systems with Xen support”, regardless of your size, you may be eligible to join the pre-disclosure list. Please see the security policy for details on eligibility and how to apply.
It also means that if you are currently on the list, you will be asked to come in line with the changes to the policy: namely, to have a security alias for your organization rather than an individual, and to send a statement saying that you have read this policy and will abide by it.
As it is widely know, really tough Open Source users –the ones that wear sandals, colored hats of various kind, and are equipped with long enough UNIX beards– always install software via tarballs and some good old
./configure-make-make-install-fu! Then there are the developers, who couldn’t care less about installing: all that matters is from where you can checkout –well, actually, this days it’d better be
git clone– the code. Once you got it, and you compile it with no errors, what else is remaining and what on Earth you want to install it for, right?
(Un?)Fortunately, there exist different kind of people too. They, whiskered or not, are usually very happy every time they can avoid dealing with either tar or git, and can start using some software by only sending a couple of directives to their favorite distribution’s package manager. That, usually, means a loot of cool things, like automatic dependency tracking, cleanup upon uninstall, smooth update to new versions, and all this kind of stuff. However, for this to work, it is required that someone has stepped up to act as the package maintainer of that particular software for the specific distribution. Package maintainers are in a very peculiar spot. In fact, wrt the software they package, they’re not regular users, nor they (not necessarily, at least) act as core developers for it, and yet they play an important role in determining the degree of success of a project.