The OpenStack community has recently released the Essex release, which supports XCP and XenServer. A number of vendors have worked at that support including Citrix, Internap and Rackspace Public Cloud. You can find some more information about Xen support in the OpenStack Essex release at this wiki page. If you are interested in what has changed in Xen support fro Essex check out this blog post.
Note that there is a roadmap session on XenAPI support in at the OpenStack Design Summit later today: XenAPI (XenServer/XCP) Folsom Roadmap at 2pm, PST. If you are at the Design Summit and care about Xen support, why not drop in and meet Ewan Mellor, John Garbutt or Renuka Apte.
Of course, project Kronos is almost completed, which will help Xen support in OpenStack. You can find information about XCP-XAPI in Debian in the Debian package repository (for docs see Debian XCP wiki and this tutorial). XCP-XAPI support in Ubuntu is near complete: we are waiting for the XCP-XAPI packages to be synced to Ubuntu (see ticket #962184). Documentation can be found in the manpages and the XCP-XAPI package description.
Fedora is planning a number ofÂ test days as part of their release cycle, including aÂ Virtualization Test Day on April 12th (this Thursday).
Information about the virtualization test day can be foundÂ here. We will have some people hanging out on IRC atÂ #fedora-test-day and you can also get in touch with us via the usual channels.
We have some Xen-specific information here.
Xen 4.2 will contain two new scheduling parameters for the credit1 scheduler which significantly increase its confurability and performance for cloud-based workloads:
ratelimit_us. This blog post describes what they do, and how to configure them for best performance.
The timeslice for the credit1 has historically been fixed at 30ms. This is actually a fairly long time — it’s great for computationally-intensive workloads, but not so good for latency-sensitive workloads, particularly ones involving network traffic or audio.
Xen 4.2 introduces the
tslice_ms parameter, which sets the timeslice of the scheduler in milliseconds. This can be set either using the Xen command-line option,
sched_credit_tslice_ms, or by using the new scheduling parameter interface to
# xl sched-credit -t [n]
I’m Wei Liu, a graduate student who is pursuing his master’s degree from China. If you read posts on blog.xen.org from time to time, you might remember me. I was participant of Google Summer of Code 2011 and worked on “Virtio on Xen” project for Xen.org. It turned out that I managed to contribute my humble two cents to open source Xen during GSoC, so Citrix (the backing company of Xen.org) offered me an internship position in Cambridge, UK.
The internship is almost over, so I thought it would be nice to share my experience of GSoC, working for Xen platform team, what I’ve learned and what I’ve accomplished so far.
Talking about GSoC now seems weird, but the point is I never wrote about it last year after I finished my project, so it is worth mentioning it now. Further more, GSoC is the starting point when I started to seriously work for open source Xen, it will make a good beginning of my story.
Today, Citrix and the Apache Software Foundation (ASF) announced that it will relicense the CloudStack open source project under the Apache License and contribute the CloudStack code to the ASF. Before I explain why this is good for the Xen community and the Open Cloud, I wanted to congratulate CloudStack to become the first cloud platform in the industry to join the ASF.
CloudStack has always been open source, with Citrix as the vendor behind the project. Moving from a privately operated open source community to the ASF has a number of implications: Citrix is giving up control over the project and it is moving to a collaborative and meritocratic development process, which values community, diversity and openness. For a community guy like me this is really exciting!
So why is this good news for Xen? In fact, the internal discussions preceding this decision already made a big impact: more staff within Citrix are engaged with open source and are actively supporting and understanding projects such as Xen, Linux and of course CloudStack. My experience as open source guy in various organisations is that open source and community can be easily made the responsibility of a few people and then be forgotten about. However, to be truly successful in the long haul, knowledge and support for open source in an organization needs to be broad. In the last few months the level of understanding and support for Xen across Citrix has increased hugely. You may not yet see the impact of all this: good initiatives and change need planning and take time. Donâ€™t get me wrong: on many counts Xen is a very successful project. We have an active developer community, we have a huge user base, many successful products and businesses were built on Xen, etc. But the project could have done and can do better!
When I was at Scale 10x earlier this year, Greg DeKoenigsberg from Eucalyptus said in his keynote that most cloud projects are open source today, well sort of! To me that said it all: the more cloud related projects move from single vendor driven projects to independent and community driven projects, the better for the user and the “Open Cloud”. Why? Simple: independent projects increase the user’s ability to be in control of their infrastructure by influencing the projects they care about. Thus, CloudStack becoming an Apache project, is a major milestone for achieving a better and more open cloud. Of course, the same thinking lies behind the creation of the OpenStack Foundation, which we will hopefully see later this year.
We have hit the next milestone in the release plan for Xen 4.2:
19 March â€” TODO list locked down
- 2 April â€” Feature Freeze WE ARE HERE
- Mid/Late April â€” First release candidate
- Weekly â€” RCN+1 until it is ready
We are therefore now in Feature Freeze for Xen 4.3! Patches which have been posted before or which address something on the TODO list are still acceptable (for now, we will gradually be getting stricter about this), everything else will be deferred until 4.3 by default.