– July 9, 2013
Xenproject.org is pleased to announce the release of Xen 4.3.0. The release is available from the download page:
Xen 4.3 is the work of just over 9 months of development, with 1362 changesets containing changes to over 136128 lines of code, made by 90 individuals from 27 different organizations and 25 unaffiliated individual developers.
Xen 4.3 is also the first release made with using the roadmap to track what people were doing and aim for what to try to get into this release, as well as the first release to have consistent Xen test days. This, combined with the increased number of contributors, should make this one of the best Xen releases so far. Read on for more information.
Probably the biggest single feature of this release is the experimental support for ARM virtualization, both 32-bit and 64-bit variants. The 32-bit port of Xen boots on ARMv7 Fast Models, the Cortex A15 Versatile Express platform and the Arndale board (equipped with the Exynos5 SoC by Samsung). It can boot dom0, create other virtual machines and it supports all the basic virtual machine lifecycle operations. Hardware is not yet available for 64-bit ARM processors yet, but Xen is running well in 64-bit mode on AEMv8 Real-time System Models by ARM.
Posted in Announcements, Xen Development, Xen Hypervisor.
– July 4, 2013
Yes, apparently Schrödinger’s cat is alive, as the latest release of Fedora – Fedora 19, codename Schrödinger’s cat– as been released on July 2nd, and that even happened quite on time.
So, apparently, putting the cat ”in a box” and all the stuff was way too easy, and that’s why we are bringing the challenge to the next level: do you dare putting Schrödinger’s cat “in a virtual box”?
In other words, do you dare install Fedora 19 within a Xen virtual machine? And if yes, how about doing that using Fedora 19 itself as Dom0?
Posted in Uncategorized, Xen Case Study, Xen Hypervisor.
– June 28, 2013
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).
Posted in Xen Development.
– June 27, 2013
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.
Posted in Uncategorized.
– June 25, 2013
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.
Posted in Community.
– June 20, 2013
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.
Posted in Announcements.
– June 17, 2013
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.
Posted in Announcements.
– June 12, 2013
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.
Posted in Xen Case Study, Xen Development, Xen Hypervisor.
– June 7, 2013
This is just a quick reminder of some upcoming changes to the Xen project websites (as originally outlined here).
Archiving of xen.org
Tomorrow morning GMT, we will be archiving xen.org. This means that the content on xen.org is moved to www-archive.xenproject.org. The site will be archived: in other words there will be no more updates to www-archive.xenproject.org.
Permanent redirects will be put in place from xen.org to either xenproject.org or www-archive.xenproject.org. Which location we will redirect to, depends on the content of a page:
Posted in Uncategorized.
– June 4, 2013
With the release process for Xen 4.3 in full swing (we intend to release the third release candidate this week) and with the Xen Test Days initiative (the next one is this Wednesday 5 June, join us on IRC freenode
#xentest) I thought it would be useful to offer up some information and guidance on how the Xen project deals with bug reports and how to report bugs against the Xen Hypervisor Project.
Reporting a Bug
Confirm That Your Issue Is a Bug
Experience has shown that oftentimes what appears to be a bug is often just a misconfiguration or misunderstanding of how things are supposed to work. This can be down to a lack of documentation (a perennial problem for Open Source projects and something which we are working to address with our regular Xen Document Days) or the inherent complexity of something of the things which one can achieve (or try to achieve!) using Xen.
With that in mind it is often useful to try seeking help via other means before resorting to submitting a bug report. Useful resources for asking questions are:
- In a Xen system logs the logs can usually be found in
/var/log/xen and will sometimes provide useful insight into an issue.
- Search engines. As well as simply searching for key terms relating to your issue you can also search the User and Developer list archives.
Posted in Xen Hypervisor, Xen Support.