Tag Archives: xen project developer and design summit

Now Accepting Submissions for Xen Project Developer and Design Summit 2017

screen-shot-2017-03-14-at-17-02-17 
We’re excited to announce that registration and the call for proposals is open for Xen Project Developer and Design Summit 2017, which will be held in Budapest, Hungary from July 11-13, 2017. The Xen Project Developer and Design Summit combines the formats of Xen Project Developer Summits with Xen Project Hackathons, and brings together the Xen Project’s community of developers and power users.

Submit a Talk

Do you have an interesting use case around Xen Project technology or best practices around the community? There’s a wide variety of topics we are looking for, including security, embedded environments, network function virtualization (NFV), and more. You can find all the suggested topics for presentations and panels here (make sure you select the Topics tab).

Several formats are being accepted for speaking proposals, including:

  • Presentations and Panels
  • Interactive design and problem solving sessions. These sessions can be submitted as part of the CFP, but we will reserve a number of design sessions to be allocated during the event. Proposers of design sessions are expected to host and moderate design sessions following the format we have used at Xen Project Hackathons. If you have not participated in these in the past, check out past event reports from 2016, 2015 and 2013.

Never talked at a conference before? Don’t worry! We encourage new speakers to submit for our events and have plenty of resources to help you prepare for your presentation.

Here are some dates to remember for submissions and in general:

  • CFP Close: April 14, 2017
  • CFP Notifications: May 5, 2017
  • Schedule Announced: May 16, 2017
  • Event: July 11-13, 2017

Registration

Come join us for this event, and if you register by May 19, you’ll get an early bird discount :) Travel stipends are available for students or individuals that are not associated with a company. If you have any questions, please send a note to community.manager@xenproject.org.

Will you give Xen a ride … or will Xen give you a ride?

And by “a ride”, we actually mean a ride. Like this:

 

8275748195_4a18513755_z

Like, will Xen run in your car?  Well, it appears it will!

It all started with ARM Support

In fact, Xen Project developers started woking on supporting the ARM architecture (with hardware virtualization capabilities) a couple of years ago. The goal was simple: as soon as ARM server are available, it must be possible to run Xen Project software on them. That goal has been achieved, but that is another story!

It is well known that processors employing the ARM architecture are powering already the vast majority of the so called Embedded Systems, ranging from phones, tablets and smart TVs up to cars or even airplanes. But does that mean that at some point we will start to see virtualization capable chips in cars? And if yes, when? The answers to these questions are “Yes” and “really really really soon”! In fact, the Xen Project Hypervisor is uniquely placed to support this new range of use-cases. Its isolation and security features, flexible virtualization mode and architecture, not to mention driver disaggregation and the fact that it now supports ARM (and does it with only ~90K lines of code), make it a perfect fit for the embedded world.

Some Recent ‘History’

Mobile and embedded virtualization on ARM has a long history within the Xen Project, with research projects such as Samsung’s ARM PV port and the Embedded Xen effort. However these projects were mainly research focused. With ARM support becoming a part of the Xen Project Hypervisor last year and various market factors coming together, Xen Project based products are now on the horizon. Last autumn was pivotal in generating momentum for this concept. A number of companies showed real demos and prototypes at our 2013 Developer Summit, such as

  • The Xen Project Hypervisor running on a Nexus 10 (slides and video)
  • The Xen Project Hypervisor powering an in-vehicle infotainment (IVI) system, and other systems on the TI Jacinto 6 automotive platform designed for cars (slides and video).

Since then, momentum has built within the community – as can be seen on xen-devel mailing list discussions – to port embedded OSes to the Xen Hypervisor  (some examples: FreeRTOS, Erika and QNX). Contributions and patches for making The Xen Project Hypervisor work better in such environments started to arrive too, from individuals, research institutions and small and big companies. Among the companies, GlobalLogic Inc., a full-lifecycle product development services company, has made the largest contribution so far, but we must also mention DornerWorks, GaloisUniversity of Washington and Evidence (in collaboration with the University of Modena).

A summary of the past and ongoing activities of this kind is below:

What about now?

On Monday (we told you: “really really really soon” :-D), The Xen Collaborative Project and The Linux Foundation announced a new Embedded and Automotive initiative. Artem Mygaiev, AVP Development at GlobalLogic, will serve as the Embedded and Automotive Project Lead.

The Embedded and Automotive team within The Xen Project intends to build a platform around the Xen Hypervisor that enables using it for all the non-data center use cases (automotive, internet TV, mobile, etc.) by providing a community focal-point within the Xen Project community as well as within the wider open source community.

The team plans to:

  • develop and upstream necessary changes to The Xen Project Hypervisor and Linux
  • implement new drivers (such as GPU, HID, …), protocols, capabilities and functionality that are needed for a complete automotive/embedded/mobile virtualization stack
  • upstream all necessary changes to support such functionality in operating systems that are needed for these use-cases (e.g. Android, Linux, etc.)

For the occasion, Alex Agizim, CTO of Embedded Systems at GlobalLogic, which also is a member of The Linux Foundation Automotive Grade Linux Steering Committee, said:

With ARM support, Xen Project technology is a perfect fit for embedded systems and automotive use. For example, our Nautilus platform, based on The Xen Project virtualization, enables ourin-vehicle infotainment (IVI) and auto manufacturing partners to quickly and cost-effectively develop hybrid Android/Linux-based systems. Using Nautilus, developers are able to run multiple sandboxed OSes on a single System-on-Chip (SOC). This provides superior functionality and security for both infotainment and operational functions within a car.

The latest demo of GlobalLogic‘s Nautilus Platform has been shown at the latest edition of the Automotive Linux Summit, in Tokyo. Check out the video and slides. We also heard about further use cases for Xen Project Software at this week’s Developer Summit. The rate of innovation in our community in this area is staggering: fasten your seat belts! We will tell you about these more in an upcoming event report. All this activity is also creating many benefits for the cloud and traditional server use use-cases. Certification will lead to quality improvements across shared components. Realtime scheduling can be used for graphics and gaming use-cases in the cloud and for Network Function Virtualization. And so on, and so on, …

Learn More

GlobalLogic, in partnership with The Linux Foundation, will present a free webinar at 9 a.m. PDT, Wednesday, August 27, 2014, titled “Virtualization in the Automotive Industry.” Register today to learn how Xen Project technology adds reliability and security when adopting virtualization for automotive software development.

Vendors and individual developers interested in collaborating on embedded, automotive and mobile use cases are encouraged to join the new Xen Project subproject at http://xenproject.org/developers/teams/embedded-and-automotive.html.

Customers Call the Shots — Verizon Cloud Adds Business Value with Quality of Service

dslutz

Both businesses and consumers rely on public clouds for a range of tasks and activities from collaboration and video streaming to gmail and Netflix. New companies are born with just a dozen employees, a laptop and an Internet connection practically overnight. This is all thanks to cloud computing.

It’s no surprise that in the next six years, almost 90 percent of new spending on Internet and communications technologies, a $5 trillion global business, will be on cloud-based technology, according to industry analyst firm IDC. Cloud applications will also account for 90 percent of total mobile data traffic by 2018, according to the Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2013–2018.

The benefits for users are almost too numerous to count, but most IT professionals agree that cloud computing epitomizes constant change. Its ability to provide ubiquitous, on-demand access to a shared pool of networks, servers, storage, and services whenever and wherever they are needed is creating both market opportunity and market upheaval.

To temper the turbulence, capitalize on the opportunities and best prepare for any number of cloud unknowns, several of the world’s largest public providers including Amazon Web Services, Rackspace, IBM/SoftLayer and Verizon Terremark rely on Xen Project virtualization. Open source Xen Project software offers superior IT efficiencies, workload balancing, hyperscalability and tight security by running VMs on a cloud service.

While today the media is focusing on price wars and the possible commoditization of infrastructure as a service (IaaS), cloud providers like Verizon Terremark are innovating with novel Quality of Service agreements and new levels of automation. In his talk in Chicago at our Xen Project Developer Summit, Verizon Terremark’s Don Slutz will present an overview of the Verizon Cloud architecture based on Xen.

“It’s the core foundation of the Verizon Cloud, allowing our users to run any type or size workload they’d like to. Xen is critical to Verizon. Competing solutions were either too cost prohibitive or lacked the security controls that Xen has,” Don said.

Verizon Terremark is a long-time advocate of open standards and is more actively involved than ever before in the open source ecosystem. Verizon sponsors and participates in Xen Project software, invests in CloudStack and most recently joined the Cloud Foundry Foundation, hoping to see the cloud market mature quickly and provide businesses with cloud-based offerings that address specific needs like performance, choice, cost and flexibility.

For the past three years, Don has worked on integrating and designing Xen for the Verizon Cloud architecture along with seven full-time engineers. Today, clients are fully deployed on Verizon’s IaaS based on Xen. A focal point of his talk will be Verizon’s Quality of Service (QoS) goals with CPU, memory, network and disk performance.

“Often clouds end up requiring far too much support personnel, which we are trying to rectify. With our QoS agreement, we allow users to set the performance parameters their business requires and guarantee that Verizon will back these up at all times. Instead of focusing on speed or load size, we’ll guarantee certain CPU, memory, network or disk performance. This is really unique in the industry,” he added.

In addition to delivering workload efficiency, security and cost savings to its cloud customers, Verizon is also giving back to the Xen Project community.

“We’re working to make Verizon Cloud a high capacity service that allows people to move existing VMs easily onto it it,” Don said. “Our goal is to add enough VMWare support so that a guest can be exported from VMWare and automatically run without any changes on Xen.”

Verizon’s VMWare code is currently in review and in the past year has contributed 40 change sets that totals 4,300 lines of code.

Proof that demand for cloud services is growing and spurring more change, Don will also address Verizon’s design goals to move from three to seven data centers in the near future. If you’re interested in learning more, be sure to register today for the Xen Project Developer Summit to hear Don present on Tuesday, August 19 from 9 to 9:45 a.m.

About Don Slutz
Currently, Don works for Verizon Terremark enhancing Xen, which is the basis for Verizon Cloud. He got started early (1970) in computers because of his father Dr. Ralph J. Slutz and spent 16 years at Prime Computer in operating systems. He has extensive networking, performance, and testing experience.

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).

So, How’s Xen on Debian?

So, how many of you use Debian? I bet a lot. Well, here it is what the Debian Xen package maintainers told The Xen Project, when asked a few questions. We are talking about Bastian Blank and Guido Trotter. In fact, they share the burden, with Bastian doing “most of the work nowadays” (Guido’s words) and Guido “starting packaging Xen many years ago, while assisting with stable security updates lately” (ditto).

You’ll discover that they particularly like the Xen architecture, and this makes us really really proud. It also look like a shorter release cycle for Xen is in the wishlist. Well, Xen 4.3 cycle has already been way shorter than its predecessors, and the feeling is the future will be even better!

However, the most surprising thing is that coffee is quite unpopular with them too, as it was already the case for Maarten from Mageia… I am honestly starting to think whether this could be a ‘package maintainers’ thing’!

Anyway, sincere thanks to both Bastian and Guido for finding the time for this interview, and let’s get straight to their answers!

Continue reading

Schrödinger’s Cat in a (Xen) Virtualzed ‘Box’

Fedora Logo

Fedora Logo

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?
Continue reading