Monthly Archives: October 2013

Announcing the Release of Xen Project 4.3.1

We are pleased to announce the release of Xen 4.3.1.  The is the latest point release in the Xen 4.3 series of releases.

Downloads:

This is available immediately from its git repository:

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

It is also available for download from the XenProject.org website:

xenproject.org/downloads/xen-archives/supported-xen-43-series/xen-431.html

Fixes:

This fixes the following critical vulnerabilities:

  • CVE-2013-1922 / XSA-48 qemu-nbd format-guessing due to missing format specification
  • CVE-2013-2007 / XSA-51 qemu guest agent (qga) insecure file permissions
  • CVE-2013-1442 / XSA-62 Information leak on AVX and/or LWP capable CPUs
  • CVE-2013-4355 / XSA-63 Information leaks through I/O instruction emulation
  • CVE-2013-4356 / XSA-64 Memory accessible by 64-bit PV guests under live migration
  • CVE-2013-4361 / XSA-66 Information leak through fbld instruction emulation
  • CVE-2013-4368 / XSA-67 Information leak through outs instruction emulation
  • CVE-2013-4369 / XSA-68 possible null dereference when parsing vif ratelimiting info
  • CVE-2013-4370 / XSA-69 misplaced free in ocaml xc_vcpu_getaffinity stub
  • CVE-2013-4371 / XSA-70 use-after-free in libxl_list_cpupool under memory pressure
  • CVE-2013-4375 / XSA-71 qemu disk backend (qdisk) resource leak
  • CVE-2013-4416 / XSA-72 ocaml xenstored mishandles oversized message replies

We recommend all users of the 4.3 stable series to update to this latest point release.

Among the bug fixes and improvements (around 80 since Xen 4.3.0):

  • Adjustments to XSAVE management
  • Bug fixes to nested virtualization
  • Bug fixes for other low level system state handling
  • Bug fixes to the libxl tool stack

10 years of Xen : Transforming a Dinosaur
into a Bird (or winged Panda)

Xen Hypervisor development started at Cambridge University as part of the Xenoserver research project in the late 90’s. The goal of Xenoserver was ambitious:

The Xenoserver project is building a public infrastructure for wide-area distributed computing. We envisage a world in which Xenoserver execution platforms will be scattered across the globe and available for any member of the public to submit code for execution. The sponsor of the code will be billed for all the resources used or reserved during the course of execution. This will serve to encourage load balancing, limit congestion, and hopefully even make the platform self-financing.

Today, this model of computing is called cloud computing. And the Xen Hypervisor was – and indeed is today – instrumental in enabling the biggest cloud in production. Not only are Amazon Web Services and Rackspace Public cloud based on Xen. New large deployments such as Verizon Public Cloud also chose Xen as basis for their offering.

Happy 10th Birthday

On October 21st, 2003 at the 19th ACM Symposium on Operating Systems Principles the Xen Hypervisor was first revealed as an open source project to the public. Exactly 10 years ago. Time to wish the project a Happy 10th Birthday!

The Burden of being First :
Or what happened to the Dinosaurs?

Sometimes being the first open source project in its field can become a burden. Why? Because, community problems can build up unchecked. The simple fact is that lack of competition can cause complacency. This is what happened to the Xen Project. For the first few years of its life the project operated without governance, became insular, didn’t promote itself and failed to engage its users and contributors. When its first open source competitor – KVM – gathered steam, the community was slow to respond and change.

Continue reading

Xen Project to join Round 7 of the Gnome Outreach Program For Women

OPW Poster

OPW Poster

The Xen Project is pleased to announce that the Xen Project Advisory Board will be sponsoring one intern for Round 7 of the Gnome Outreach Program For Women.

The Outreach Program for Women (OPW) internships were inspired in many ways by Google Summer of Code and by how few women applied for it in the past. This was reflective of a generally low number of women participating in the FOSS development. The GNOME Foundation first started the internships program with one round in 2006, and then resumed the effort in 2010 with rounds organized every half a year. In the January-April 2013 round, many other FOSS organizations joined the program.

The application deadline for interns is November 11, 2013. For a list of projects for interns and more information on how to apply, check our Xen Project OPW portal.

Round 6 of OPW

In round 6 of the Program, we had two interns that worked on Xen Components in the Linux kernel:

  • Elena Ufimtseva worked on virtual NUMA for the Xen Project. Elena will be presenting at Xen Project Developer Summit next week. Why not come and see her talk?
  • Lisa Nguyen worked on Xen block drivers in the linux kernel’ Lisa presenter her work at LinuxCon NA 2013. Check out her slides!

We asked both Elena and Lisa to talk a bit about their work and experiences, in their own words.

Continue reading

Fedora 20 Virtualization Test Day Report

So, it was Fedora Virtualization Test Day last Tuesday and I actually went down and took the occasion for some good testing of Xen on the next Fedora release (Fedora 20, codename Heisenbug). Fedora is going to ship Xen 4.3 (and there are not many other mainstream distribution doing that), so it is very important to try to make sure it will be as good as possible for Fedora users!

A lot of information on how to (well, how you should have… but it’ll be for next time ;-P) participate  to such event are available on our Wiki. What I am up to, here, is reporting how some of the tests I did that day went. Hopefully, this would give an idea of where we stand, regarding the integration of Xen in Fedora, as well as how well Xen itself works with Fedora’s default virtualization toolstack, i.e., libvirt.

Setting up the testing environment

Well, you at least need a Fedora 20 installation, in order to test Xen on Fedora 20. For the details, have a look at the already mentioned wiki page. Here I’m only going to say that I decided to go for a PXE-boot based install, which I did by downloading the following files:

 $ wget http://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC2/Fedora/x86_64/os/images/pxeboot/vmlinuz
 $ wget http://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC2/Fedora/x86_64/os/images/pxeboot/initrd.img

and by preparing an appropriate entry in my PXE server configuration (usually a file called pxeconfig.cfg):

label fedora-20btc1-amd64-s
    KERNEL fedora/20/x86_64/Beta-TC2/vmlinuz
    APPEND initrd=fedora/20/x86_64/Beta-TC2/initrd.img repo=http://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC2/Fedora/x86_64/os/ console=ttyS0,115200n8 text serial

Screenshot from 2013-10-08 15_19_37

Mind the console=ttyS0,115200n8 text serial in case you want to run the install on a serial console, like I’m doing in this case.

On a second test box, I did a proper graphical install (still via PXE). No big difference, really, just follow the guided procedure, then grab a coffe` and wait for this screen (on the right) to happear.

Installing Xen and rebooting into Dom0

After finishing installing the host, we need to install Xen, libvirt and some libvirt related tools. It’s all described in this other Wiki page, so let’s skip it here…. Just follow that instructions and reboot into the following:

Fedora release 20 (Heisenbug)
Kernel 3.11.2-301.fc20.x86_64 on an x86_64 (hvc0)

odyn login: root
Password:

# cat /etc/fedora-release 
Fedora release 20 (Heisenbug)
# sudo uname -a
Linux odyn.uk.xensource.com 3.11.3-301.fc20.x86_64 #1 SMP Thu Oct 3 00:57:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
# virt-what 
xen
xen-dom0

Well, I guess we can make a note of the first important fact of the Test Day:

  • Fedora 20 works quite nicely and straightforwardly as Xen Dom0!

Creating guests

Ok, let’s move forward to creating some guest. In Fedora, when you want to create and install a guest, especially a Fedora guest, you do it with virt-install. Period. So, let’s do that, a Fedora 20 PV guest, on a Fedora 20 Dom0, with virt-install, installed from the serial console too. It’s actually more easily done than said:

 # lvcreate -nf20_64 -L10G /dev/fedora_odyn
 # virt-install --paravirt --name f20_64 --ram 2048 --vcpus 4 -f /dev/fedora_odyn/f20_64 --network bridge=virbr0 --location http://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC2/Fedora/x86_64/os/ --graphics none
=====================================================================
Installation

 1) [x] Installation source               2) [!] Timezone settings
        (http://dl.fedoraproject.org/pu          (Timezone is
        b/alt/stage/20-Beta-TC1/Fedora/          not set.)
        x86_64/os/)                       4) [!] Set root password
                                                 (Password is not set.)
 3) [!] Install Destination               6) [!] Software selection
        (No disks selected)                      (GNOME Desktop)
 5) [!] Create user
        (No user will be created)
 7) [x] Network settings
        (Wired (eth0) connected)
  Please make your choice from above ['q' to quit | 'c' to continue |
  'r' to refresh]: 
[anaconda] 1:main* 2:shell  3:log  4:storage-log  5:program-log

Let’s now head to my second test box, and do something similar, which lead us where this screenshot shows:

Screenshot from 2013-10-08 16_50_31

I also created another PV guest and an HVM guest there, with similar procedures. From all this, we can reasonably assess the following:

  • Fedora 20 works fine both as a PV and HVM Xen guest.

Playing with the guests with virsh

Now, what about, seeing what we have running:

# virsh list
Id Name State
----------------------------------------------------
39     F20-HVM                               running
40    fedora20                               running

Pausing and resuming both the PV and HVM guests:

# virsh suspend F20-HVM
Domain F20-HVM suspended
# virsh suspend fedora20
Domain fedora20 suspended
# virsh list
Id Name State
----------------------------------------------------
39      F20-HVM                               paused
40     fedora20                               paused

# virsh resume F20-HVM
Domain F20-HVM resumed
# virsh resume fedora20
Domain fedora20 resumed
# virsh list
Id Name State
----------------------------------------------------
39     F20-HVM                               running
40    fedora20                               running

And, finally, saving-&-restoring one of them

# virsh save fedora20 /tmp/savefile
Domain fedora20 saved to /tmp/savefile
# virsh list
Id Name State
----------------------------------------------------
39      F20-HVM                              running

# virsh restore /tmp/savefile
Domain restored from /tmp/savefile
# virsh list
Id Name State
----------------------------------------------------
39      F20-HVM                              running
41     fedora20                              running

I also tried importing and cloning a VM, as described here and here, and it all worked.

Any issues, then? There indeed was one. Basically, it looks like reaching the guest’s PV console via virsh does not work, while it is fine with xl console:

# virsh console fedora20
Connected to domain fedora20
Escape character is ^]
error: internal error: cannot find character device (null)

# xl console fedora20
Fedora release 20 (Heisenbug)
Kernel 3.11.2-301.fc20.x86_64 on an x86_64 (hvc0)

fedora20 login: root
Password:
[root@fedora20 ~]#

And I will of course report that to the appropriate mailing list/bugzilla.

What’s there, what’s missing

The previous section reveals that not only Xen is straightforward to install and works quite well on Fedora 20 as a Dom0, and that Fedora 20 works quite well as a Xen PV or HVM guest. It also shows how the basic VM lifecycle of a Xen guest, in Fedora 20, can be handled nicely enough with libvirt and the related tools (virt-install, virt-manager, virt-viewer, etc.). That of course does not exclude the possibility of using Xen’s default command line toolstack (xl).

The only two relevant missing features, at the time of writing, in the libvirt libxl driver are:

  • PCI Passthrough
  • live migration

Yes, big ones, I know. However, consider the following:

  1. that does not mean that PCI Passthrough and migration does not work on Xen on Fedora at all. They do work via the xl toolstack, they are just not available via libvirt;
  2. this is going to be solved soon, as the libvirt libxl driver maintainer Jim Fehling reported recently on xen-devel. In fact, this is the patch series for PCI Passthrough, and this is the patch series implementing live migration, and there are pretty good chances that both these patches make it in libvirt before Xen 4.4 release time (so, not in time for Fedora 20, but still not bad at all).

So, stay tuned since, as Jim says, “Slowly, with each libvirt release, the libxl driver is improving”.

Conclusions

Fedora really does a great job with these Test Days. All of it: the planning, the managing, the reporting… An example that many other project should look at and try to follow (and actually, Xen Project is trying, as we also started having Xen Test Days).

Participating to the latest Fedora Virtualization Test Day has been really nice, although we need to do a better job in convincing more Xen folks to be there and do some Xen specific testing. Anyway, I am really glad to have had the chance to verify how well Xen 4.3 will work on Fedora 20.

It is actually quite important that we get a good Xen on Fedora test coverage, at least as far as running the next release of Fedora as a Xen DomU is concerned. In fact, being a functional Xen guest is one of the release blockers for a Fedora release, as in, if release X does not work as a Xen guest, it can’t be released!

Since testing Xen on Fedora is, for the most part, testing Xen integration with libvirt, what about producing some libvirt test-cases for OSSTest? That would be very cool, and we are already working on it. Another interesting thing would be to also have OSSTest could try to build and run Xen on various distro (as host), instead than using only Debian, as it is doing right now. This is a bit more tricky than the above, but we are thinking at how to do that too (standalone mode could, perhaps, help).

Xen Project User Summit Videos Available

xen_user_summit_bgFor those community members, who could not attend the Xen Project User Summit in New Orleans, we now published all the videos on our video stream. For your convenience, we also created a portal page that links to all recordings of the user summit. Again, a big Thank You to our speakers and to Russell Pavlicek for organizing the event.

Event Recordings and other information on Events

events-on-videoIn future, we will be recording all Xen Project events such as user and developer summits. You will be able to find recordings of Xen Events on the events page in a box marked Xen Events On Video. Also, if you want to know if there are any Xen talks at an event you are planning to attend, why not check out our events calendar?

Don’t Forget: Xen Project Developer Summit is around the corner

A quick reminder: our Developer Summit is just round to corner! We have a great line up of topics covering the latest developments in server and cloud to new frontiers in virtualization in mobile, automotive and embedded!

Fedora 20 Virtualization Test Day is today!

Fedora Logo

Yes, today (Tuesday, October 8th) is one of the Fedora 20 Test Days, more specifically, Virtualization Test Day.

Specific information regarding testing Xen on the new Fedora can be found in this Wiki page. For attending and participating, join us now on IRC at #fedora-test-day (Freenode)!

Fedora 20 will be one of the first mainstream distros shipping Xen 4.3, so come and help us making sure it will work great for you and all Fedora users!!