Xen Project Starts the New Year with a Bang!

January Features Major Xen Project Activities at Two of the Biggest FOSS Conferences of the Year!

The Xen Project is starting 2016 on a high note by sponsoring major events at both the largest community-run FOSS conference in North America (SCALE) and the world (FOSDEM). In addition to a flurry of technical talks in the main program of each conference, Xen Project is organizing additional co-located events.

Unikernels and More: Cloud Innovators Forum (CIF16) Comes to Southern California Linux Expo (SCALE)

Xen Project is proud to announce the world’s most wide-ranging Unikernel user event ever held! We have a full day of talks which cover everything from the basics of Unikernels to building Unikernels to reworking the cloud to adapt to the realities of Unikernels. We have speakers from some of the biggest research companies (like IBM, NEC, and Ericsson) as well as some of the most leading edge organizations. Just take a look at the talk lineup:

To join us, simply register at the SCALE 14x website.

And all this is in addition to a couple Xen Project talks in the SCALE program itself:

Xen Project talks at FOSDEM

As in past years, the Xen Project will have a booth and demos at FOSDEM and is well represented at FOSDEM Devrooms.

To join us, simply attend FOSDEM (no registration required) and enjoy the talks.

Future of Xen Project: Video Spotlight Interview with Citrix’s George Dunlap

In this video, George Dunlap Senior Engineer of Citrix explains how and why Citrix works with the Xen Project, why companies use Xen Project Hypervisor, and new opportunities for the future of this technology.

Citrix Systems designs, develops and markets technology solutions that enable information technology (IT) services. Citrix has always been committed to the community and consistent in its principles of transparency and neutrality, helping the Xen Project maintain its position as one of the leading open source hypervisors.

One of the major benefits of being a part of the Xen Project is the multiplier benefit that comes with contributing code to open source communities. For example, if Citrix contributes 25% of the code, the equivalent of hiring 25 engineers, it receives 100 engineers’ worth of development as part of the Xen Project. This helps Citrix build the most efficient enterprise products possible and also allows the company to take an active role in leading the Xen Project Hypervisor into the future.

How has this collaboration been put into action? Most recently, Xen Project announced its 4.6 release, which was built into Citrix’s XenServer Dundee (this recently entered beta 1).*

As virtualization moves beyond simply being used for services, and expands into networks, mobile, automotive, and more embedded systems, features like isolation for security, lightweight for mobile, and high performance will continue to help Xen Project Hypervisor grow and support the next stage in cloud computing and virtualization. And Citrix will be there to help further this growth.

*XenServer Dundee has not been released and its feature set has not been finalized.

 

Xen Project Contributor Training v2

Two weeks ago, I embarked onto a road trip to China with the aim to meet Xen Project users as well as contributors. I visited a number of vendors in Hangzhou and Beijing on this trip. Part of the objective was to give training to new contributors and developers, and to strengthen existing relationships.

Hypervisor contributions from Chinese developers

Hypervisor contributions from Chinese developers

A year ago I travelled to China and pioneered our developer training, because many of our Chinese developers had some challenges working with the community. The good news is that the training activities have helped, which can be seen in contribution statistics. This leads us to the “bad news”: a new group of developers joined the community, who could benefit from training. In addition, a lot of process and operational changes are currently discussed or have recently taken place within our community.

What is remarkable, is that many of the latest contributors to the project have only recently graduated from University (in 2014 or 2015). Working with the Xen Project and Linux was often their first experience with open source. Working with open source projects is not always easy, in particular when doing so in a non-native language and with a manager behind you, who expects that you get a feature into an open source project by a certain time. In addition, as a community we need to balance the needs of different stake-holders (enterprise, cloud, embedded, security companies) and make informed decisions on the relative importance of new features vs. quality vs. security vs. … which has led to increasingly strict criteria and more and more scrutiny, when reviewing code contributions. This means, that contributing to the project for the first time can sometimes feel like a real challenge. Part of the reason why I regularly travel to China, is to explain what is happening in the community, to explain that all members of the community can influence and shape how the project is run and to understand local community issues and address them as they occur.

Contributor Training v2

Since the creation of the training material last autumn, there have been a few changes in how the project operates. Most notably in the Security Vulnerability Management Process and Release Management. Many other areas of how the project operates are also being reviewed and discussed. The goals behind these discussions and proposed changes intend …

  • to make the communities’ development processes more efficient and scalable.
  • to make conscious decisions about trade-offs, such ease of feature contribution vs. quality and security.
  • to make it easier for newcomers to join the project.
  • to encourage more contributors to review other people’s code, test our software, write test code and make other non-code contributions to the project.

Thus, I updated our training material to reflect these changes and added new material. It is divided into 4 separate modules, each of which takes approximately 2.5 hours to deliver. The training decks are designed as reference material for self-study. Each training module has many examples and embedded links in it. The material is available from our Developer Intro Portal as slides or as PDFs. I embedded the updated and new training modules into this blog for your convenience:

If you have any questions, feel free to ask by contacting me via community dot manager at xenproject dot org and I will improve the material based on feedback. My plan is to keep the training material up-to-date and to modify it as new questions and new challenges arise.

Xen Project 4.7 Planning Opens

With Xen 4.6 released in October, we are already one month into the new cycle. Which means it is time to start planning for the next release. You may remember that one of the goals of the 4.6 release planning was to create smoother developer experience and to release Xen 4.6 on time. Both goals were achieved, so it was time to think where to go from here. Thus, the Xen community underwent a thorough discussion on how to manage future releases from xen-unstable and its impact on stable releases. The takeaway message of those lengthy threads is that we should continue to work on making the release cycle shorter and more predictable.

As such, the timeline for 4.7 is:

  • Development starts: October 13, 2015
  • Last posting date: March 18, 2016
  • Hard code freeze: April 1, 2016
  • Release date: June 3, 2016

After the 4.7 release, we will start to release Xen every 6 months: at the beginning of June and December. A regular 6 monthly release schedule has worked well for Ubuntu, OpenStack and many other projects. The idea behind it is a simple one: set a hard date and modify your goals to match that timeline. Which is also, why we dropped feature freeze exceptions, which create overheads and introduce unnecessary risk and debate. In addition, the new fixed release schedule will help open source projects and commercial vendors who consume Xen to plan their own releases better. And it allows us to set a schedule that ensures that every single release cycle is only affected by a single holiday period and that we have a Xen Project developer event (be it a Hackathon or Xen Project Developer Summit) during each release cycle. The stable release scheme is unchanged: 18 months full support, plus 18 months security fixes afterwards.

For more information, check out the slides that explain our release process and how it is changing for Xen 4.7 and beyond. To follow the roadmap in the coming months, be sure to check the Xen 4.7 Roadmap page on our wiki. Get involved on xen-devel@ and happy hacking!

For more updates, follow @XenProject.org on Twitter.

Xen Project 4.5.2 Maintenance Release Available

I am pleased to announce the release of Xen 4.5.2. Xen Project Maintenance releases are released roughly every 4 months, in line with our Maintenance Release Policy. We recommend that all users of the 4.5 stable series update to this point release.

Xen 4.5.2 is available immediately from its git repository:

    xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.5
    (tag RELEASE-4.5.2)

or from the Xen Project download page at www.xenproject.org/downloads/xen-archives/xen-45-series/xen-452.html.

This release contains many bug fixes and improvements. For a complete list of changes in this release, please check lists of changes on the download page.

Security vs Features

We’ve just released a rather interesting batch of Xen security advisories. This has given rise in some quarters to grumbling around Xen not taking security seriously.

I have a longstanding interest in computer security. Nowadays I am a member of the Xen Project Security Team (the team behind security@xenproject, which drafts the advisories and coordinates the response). But I’m going to put forward my personal opinions.

Of course Invisible Things are completely right that security isn’t taken seriously enough. The general state of computer security in almost all systems is very poor. The reason for this is quite simple: we all put up with it. We, collectively, choose convenience and functionality: both when we decide which software to run for ourselves, and when we decide what contributions to make to the projects we care about. For almost all software there is much stronger pressure (from all sides) to add features, than to improve security.

That’s not to say that many of us working on Xen aren’t working to improve matters. The first part of improving anything is to know what the real situation is. Unlike almost all corporations, and even most Free Software projects, the Xen Project properly discloses, via an advisory, every vulnerability discovered in supported configurations. We also often publish advisories about vulnerabilities in other relevant projects, such as Linux and QEMU.

Security bugs are bugs, and over the last few years the Xen Project’s code review process has become a lot more rigorous. As a result, the quality of code being newly introduced into Xen has improved a lot.

For researchers developing new analysis techniques, Xen is a prime target. A significant proportion of the reports to security@xenproject are the result of applying new scanning techniques to our codebase. So our existing code is being audited, with a focus on the areas and techniques likely to discover the most troublesome bugs.

As I say, the Xen Project is very transparent about disclosing security issues; much more so than other projects. This difference in approach to disclosure makes it difficult to compare the security bug density of competing systems. When I worked for a security hardware vendor I was constantly under pressure to explain why we needed to do a formal advisory for our bugs. That is what security-conscious users expect, but our competitors’ salesfolk would point to our advisories and say that our products were full of bugs. Their products had no publicly disclosed security bugs, so they would tell naive customers that their products had no bugs.

I do think Xen probably has fewer critical security bugs than other hypervisors (whether Free or proprietary). It’s the best available platform for building high security systems. The Xen Project’s transparency is very good for Xen’s users. But that doesn’t mean Xen is good enough.

Ultimately, of course, a Free Software project like Xen is what the whole community makes it. In the project as a whole we get a lot more submissions of new functionality than we get submissions aimed at improving the security.

So personally, I very much welcome the contributions made by security-focused contributors – even if that includes criticism.