Monthly Archives: April 2014

Welcome our GSoC and OPW participants

Google and the Outreach Program for Women (OPW) just announced GSoC students and OPW interns. I wanted to briefly introduce our students and interns and their projects, and ask you to welcome them to the project.

We had a large number of applicants and could only take the best 7 (5 students for GSoC and 2 interns for OPW). What was remarkable this year, is that 4 out of the 7 successful applicants to the Xen Project are women.

Below are the projects as listed on the Google and OPW websites:

Improvements to the block I/O paravirtualized Xen drivers

OPW Intern: Arianna Avanzini, Modena, Italy
Mentor: Konrad Rzeszutek Wilk (Oracle)
This project aims to improve paravirtualized block I/O drivers by utilizing the new block multiqueue API in Linux. That should provide greater throughput and lower latency for I/O workloads.

Implement Xen PVUSB support in xl/libxl toolstack

GSoC Student: Bo Cao, Shanghai, China
Mentors: George Dunlap (Citrix) and Pasi Kärkkäinen
libxl and xl do not currently support PVUSB functionality. This project aims to add the missing functionality (which is present in xm) to libxl and xl.

Lazy Restore Using Memory Paging

GSoC Student: Dushyant Behl, India
Mentor: Andres Lagar-Cavilla (Gridcentric)
VM save & restore functionality is one of the most commonly used features in cloud and virtualization platforms. The current implementation of VM save & restore in Xen results in loading the entire memory image of the VM from the save file, which slows down the entire process. This project will load what we call an empty VM and let the page fault handler load the pages, using memory paging to introduce the concept of lazy restore.

Mirage OS cloud API support

GSoC Student: Jyotsna Prakash, CA, USA
Mentors: Dave Scott (Citrix) and Anil Madhavapeddy (University of Cambridge)
This project will develop Mirage OS OCaml bindings for the EC2 and Rackspace cloud APIs and an example Mirage OS application that uses the API.

Mirage OS contributions and improvements

OPW Intern: Mindy Preston, Madison, WI, USA
Mentors: Richard Mortier (University of Nottingham) and Anil Madhavapeddy (University of Cambridge)
This project will deliver a number of improvements to Mirage OS such as 1) support for booting Mirage OS unikernels easily on EC2, Rackspace Cloud and OpenStack Clouds; 2) protocol bisimulations against existing Mirage OS protocol implementations; and 3) adding IPv6 support into mirage-net and a few others.

Parallel xenwatch kthread

GSoC Student: Tülin İzer, Turkey
Mentor: Boris Ostrovsky (Oracle)
Xenwatch lists running Xen domains with some properties, allow connecting to text and graphical consoles. However, Xenwatch is locked with a coarse lock that presents scalability issues when a huge number of guests is running. The project will rewrite xenwatch locking in order to support full scalability.

HVM per-event-channel interrupts

GSoC Student: Yandong Han, Beijing, China
Mentor: Paul Durrant (Citrix)
In this project, Xen is modified to allow each event channel to be bound to a separate interrupt (the association being controlled by the PV drivers in the guest). This allows separate event channel interrupts to be handled by separate vCPUs. There should be no modifications required to the guest OS interrupt logic to support this (as there is with the current Linux PV-on-HVM code) as this will not be possible with a Windows guest.

Note that a Xen Project related project was also accepted by openSUSE:

Add Snapshot management API to libvirt Xenlight driver

GSoC Student: David Kiarie
Mentor: Jim Fehlig (SUSE)

This project aims to implement a Xen virtual machines snapshot management API to the libvirt Xenlight driver to enable users of Xen to easily manage snapshots using libvirt client applications.

Call For Participation is Open for the Xen Project User Summit in New York City

Our Next User Summit to be Held on September 15 in Downtown Manhattan

Last year marked the arrival of the very first Xen Project User Summit.  This year, we are aiming to draw over 100 people to the Lighthouse Executive Conference Center in the heart of New York City to discuss the use of the Xen Project hypervisor.

How Are You Using Xen Project Software?

We are actively looking for people who are willing to talk about:

  • How you use our project’s software in your datacenter or lab
  • How you integrate the Xen Project hypervisor in your solution or cloud
  • How you control the software with custom scripts or utilities
  • Why you chose Xen Project software instead of some other hypervisor
  • How much you time or money you saved by using our software
  • Where you’d like to see our project go in the future

Also, we’d welcome talks about:

  • Features of the newest release and how to use them
  • New projects building on Xen Project software which could open new avenues for end users (like the work around GPU virtualization, cloud operating systems like MirageOS, and additional architectures like ARM)
  • Instructive HowTo sessions to educate attendees about implementing particular capabilities within the software
  • The use of related products and projects like XenServer and Xen Orchestra to make our software even more powerful in the datacenter

This promises to be one of the best opportunities for users and integrators to come together and learn from people who have plenty of insight into using Xen Project software.  This may be the best chance all year to become educated about the hypervisor and the subprojects.

We are Waiting for Talk Proposals from You!  Respond by May 31.

The submission deadline is May 31, 2014.  Go to the event’s CFP page on the Linux Foundation’s website to submit your talk proposal.

Continue reading

IVI system sandboxing: The next frontier for in-vehicle upgrades

Alex Agizim, VP and CTO of Embedded Systems at GlobalLogic, had the opportunity to speak at Linux Foundation Collaboration Summit 2014, in Napa, about their use of the Xen Project Hypervisor for building OSS-based IVI (In-Vehicle Infotainment) systems. Here’s how he described his experience to

“The evolution of in-vehicle systems is a very exciting topic, and Collab Summit confirmed for me that automotive software is currently in a state of flux. Specifically, there is a gap between the conservative automotive industry and the demands of consumers (e.g., customization, connectivity, cloud, third party apps, etc.).

Today’s consumer products require a convergence of technologies, meaning it will become crucial to cultivate partnerships between different expertises. My own company, GlobalLogic, recently became a member of the multi-disciplinary Automotive Grade Linux steering committee to help develop an automotive-grade Linux platform. Furthermore, CollabSummit enabled me to meet with forward-thinking people in communications, electronics, and embedded technology. I am excited by the possibilities presented by these meetings, and who knows, maybe I will be speaking at CollabSummit 2015 on a breakthrough in-vehicle system resulting from the partnerships I created at this year’s conference!”

More thoughts from Alex on the state of In-Vehicle Infotainment appeared recently online in Embedded Computing Design. His recent blog IVI system sandboxing is worth a full read. The part more relevant to the Xen Project is reported below.

“By leveraging the Open Source, bare metal, Xen hypervisor, developers could simultaneously run two different OSs on a single System-on-Chip (SoC) to provide:

  1. Highly reliable automotive-grade Linux or Real-Time Operating Systems (RTOSs) like Autosar and QNX for mission-critical vehicle software
  2. Highly customizable Android for infotainment software

A hybrid architecture that is based on a Type-1 hypervisor would allow developers to create an Android-based IVI system without compromising the functionality, security, or reliability of the vehicle’s operational software. Critical components such as vehicle sensors, diagnostics, and emergency services would never be impacted by third-party apps, as they would be completely enclosed within their own respective OSs. Sandboxed Linux and Android operating systems give developers the freedom to create truly customizable infotainment software without negatively impacting a vehicle’s security or reliability.”

Virtualization on ARM with Xen

This is a repost of a tutorial published initially on – Thank you to Andrew Wafaa for allowing us to repost.

With ARM entering the server space, a key technology in play in this segment is Virtualization. Virtualization is not a tool solely for servers and the data center, it is also used in the embedded space in segments like automotive and it is also starting to be used in mobile.

This is not a new technology, IBM pioneered it in the 1960s, and there are many different hypervisors implementing different methods of virtualization. In the Open Source realm there are two major hypervisors: KVM and Xen. Both are interact directly with the Linux kernel, however KVM is solely in the Linux domain whereas Xen works with Linux, *BSD and other UNIX variants.

In the past it was generally accepted that there are two types of hypervisor, Type1 (also known as bare metal or native) where the hypervisor runs directly on the host server and controls all aspects of the hardware and manages the guest operating systems, and Type2 (also known as hosted) where the hypervisor runs within a normal operating system; under this classification Xen falls into the Type1 camp and KVM fell into the Type2 camp. However the modern implementations of the hypervisors has now blurred the lines of distinction.

This time round I’ll be taking a look at the Xen Hypervisor, which is now one of the Linux Foundation’s collaborative projects. Here is a brief overview of some of Xen’s features:

  • Small footprint. Based on a microkernel design, it has a limited interface to the guest virtual machine and takes up around 1MB of memory.
  • Operating system agnostic. Xen works well with BSD variants and other UNIX systems, although most deployments use Linux.
  • Driver Isolation. This allows the main device drivers of a system to run inside the VM, which enables the VM containing drivers to be rebooted in the event of a crash or compromise without affecting the host or other guests. In the Xen model the majority of the device drivers run in virtual machines rather than in the hypervisor, as well as allowing reusing of existing OS driver stacks this allows the VM containing the driver to be rebooted without affecting the host of other guests. Individual drivers can even be run in separate VMs in order to improve isolation and fault tolerance or just to take advantage of differing OS functionality.
  • Paravirtualization (PV). This style of port enables Xen to run on hardware that doesn’t have virtualization extensions, such as Cortex-A5/A8/A9 in ARM’s case.  There can also be some performance gains for some PV guests, but this requires the guests to be modified and prevents “out of the box” implementations of operating systems.
  • No emulation, no QEMU. Emulated interfaces are slow and insecure. By using hardware virtualization extensions and IO paravirtualization, Xen removes any need for emulation. As a result you have a smaller code base and better performances

Continue reading