Born in the logic of ones and zeroes and forged in the heat of battle, two hypervisors — perceived by many as foes in the realm of virtualization–are about to unite in a way many never thought possible. Over beer and code.
That’s right. The teams behind Xen Project Developer Summit and KVM Forum recently announced plans to co-host a hackathon and social event on August 18, 2015, at the close of the Xen Project Developer Summit and on the eve of KVM Forum. Virtualization is one of the most important technologies in IT today, so it makes perfect sense for the two best hypervisor projects to collaborate and socialize at an event that celebrates their similarities and bridges that gap between all things KVM and Xen.
In this Q&A, members of the Xen Project and KVM communities share what developers can expect as well as what developers will gain by attending the joint events. To be a part of the collaboration and fun, Xen and KVM ecosystem developers, contributors and users are encouraged to submit a speaking proposal for KVM Forum and Xen Project Developer Summit by May 1.
Q: This is first time you’ve ever done a joint hackathon for Xen and KVM developers. Why are you collaborating like this? What should developers plan for and expect?
A: Brian Proffitt, oVirt Community Liaison
It was a happy happenstance that both the KVM Forum and the Xen Project Developer Summit were going to take place at the same venue right next to each other on the calendar.
We’ve actually wanted to do this for a while. Given how each project contributes heavily to libvirt and QEMU, it seemed logical to try to do a hackathon as well. While this is the first time we’re doing a joint event, this is not the first time we have worked together at a hackathon. When Rackspace hosted a Xen Project Hackathon in London last year, I know we had some KVM developers there working on libvirt with the Xen folks.
We expect old friends will be meeting again, people who have been working together only upstream will likely meet for the first time, and developers will discover common issues of both KVM and Xen. Expect lots of hacking, interesting discussions, and a newly discovered understanding of how both hypervisors work. Maybe some old disagreements will re-emerge… it could be exciting.
A: Lars Kurth, Xen Project Advisory Board Chairman
Both Xen and KVM share some components in Linux, QEMU and libvirt. In addition some developers who work on Xen, also work on KVM, and vice versa. In fact, there are a number of areas where members of each community have been collaborating for some time. Consequently there is a good amount of communication and coordination going on between both communities all the time.
At the end of the day, everyone believes that socializing with each other will improve personal relationships to enable deeper collaboration. Of course, there is also the possibility of doing code reviews, discuss design ideas, etc., by bringing people together.
A: Karen Noel, senior manager, software engineering, Red Hat
We have a lot more in common than differences. We are all experts in virtualization technology and believe strongly in open source. Open source is an interesting environment where we often collaborate and help our competition. In this case, we share common infrastructure and goals. With several other hypervisors in the market, our real competition is not each other – KVM vs. Xen – the real competitors are the proprietary virtualization technologies developed with a closed, non-community based model. Developers should plan to learn from each other, make plans that help both projects and share best practices to make both the Xen and KVM projects stronger.
Q: How are the projects similar and different today?
A: Lars:
On a low level, despite sharing components, both projects often use very different code paths with regards to what is used in Linux and QEMU. This is a consequence of both projects following a different architecture, and as a consequence following different philosophies when it comes to implementing features.
A: Karen:
The KVM and Xen hypervisors are technically very different. Each have a very different design. However, a hypervisor (just like the Linux kernel) does not live in a void, and there are some technologies that are supported by Xen and KVM—most notably OpenStack.
A: Brian:
Each project will assert that its way is best to accomplish a certain goal, but open source people are known for being willing to listen to new ideas. This is part of the culture of the open source, collaborative model. It will be important to focus on the similarities between KVM and Xen: strong ecosystems full of ridiculously talented programmers who are passionate about what they do.
Q: Do you expect joint activities to help each community innovate in any way?
A: Stefano Stabellini, senior principal software engineer at Citrix
Possibly, especially given that collaboration on actual features, while not common, is not unheard of. But the most important collaboration between Xen and KVM has always been sharing thoughts and ideas at conferences, challenging each other’s point of view, sharing experiences and giving each other suggestions. This is highly valuable to me and many in the community.
A: Karen:
It’s a certainty. Every open source event brings people together where they can communicate face-to-face and in real-time. Innovation always comes out, especially when the participants have common interests, like virtualization, and already hack on the same code in upstream projects–Linux kernel, QEMU, libvirt, open firmware, etc. Discussions on joint issues will foster new ideas that both groups can use to further their projects.
Q: What type of KVM/Xen collaboration is happening in the field today?
A: Lars:
One area of collaboration today is focused on Intel graphics support, or Intel GVT-g (also known as XenGT for Xen, and KVMGT for KVM). From what I can see, Intel aims to share the maximum amount of code between Xen and KVM in both Linux and QEMU. In the ARM world, we are also collaborating on ARM server standards. And, another area where we could potentially work together is hot patching, which was recently added to Linux 4.0. Some of this was actually started at last year’s Linux Plumbers Conference.
A: Stefano:
We already work together on bug fixes to security vulnerabilities where members of each community review each other’s patches to help one another. We are also working together on defining open virtualization standards, such as the VM System Specification for ARM Processors.
We also often have similar requirements in the Linux kernel, thus we work toward making virtualization- friendly changes in Linux. In fact, both projects are GPLv2, so sometimes actual code is shared. For example, the gic-v3 driver in Xen was contributed by a member of the community based on existing Linux code written for KVM. Marc Zyngier, the original author and KVM ARM maintainer, helped us review the code.
KVM on x86 uses a pv clock interface originally written for Xen. The KVM shadow out-of-sync code was based on the previous work by Gianluca Guida for Xen. And PV spin locks were originally written by Jeremy Fitzhardinge for Xen, but then they were completed and upstreamed in Linux by KVM engineers.
Q: Is there enough room in the market for KVM and Xen? Why or why not?
A: Lars:
Of course, both communities have been able to dramatically grow their developer and user bases in the last few years. This is a clear indicator that there is enough room for both projects.
A: Brian:
Absolutely. Look, we’re going to have our technical differences, but at the end of the day, we are both open source hypervisors and that should be the most important thing in the market. If you use KVM- or Xen-based products, then you are gaining the advantage of cutting-edge innovation at a lower cost, while not paying for proprietary software products. The marketplace has to have the choice of using open source software and not being locked in with proprietary technology. So KVM, Xen and products which use them–like oVirt, OpenStack, XenServer, and CloudStack–are a crucial part of the marketplace.
Q: How do you see KVM/Xen evolving into the future?
A: Lars:
We are actively focusing on a number of areas to further differentiate and advance Xen in cloud and data center environments. Additionally, we’re focused on advancing Xen for new opportunities in mobile, embedded, automotive, Network Functions Virtualization (NFV) and graphics virtualization. This naturally happens as our contributors and users build on our current capabilities, while identifying new features that would be beneficial in the field. For example, the capability to plug in different schedulers that have different trade-offs to give Xen users more freedom and choice is an extremely popular new feature in Xen 4.5. This trend is continuing in our current development cycle, while at the same time, there is also a strong focus on common standards and interfaces. The same is true when it comes to security related subsystems, such as vTPM 2.0 support, Xen Security Modules and Xen integration with LibVMI for VM introspection.
A: Karen:
Both KVM and Xen are mature projects. A lot of the evolution occurs in the projects that use them, such as OpenStack. Demand for new features, new configurations and optimizations puts pressure on the hypervisors, QEMU, libvirt and the management stack to collaborate more tightly to deliver quickly.
Right now there is a lot of buzz around Network Functions Virtualization (NFV) using real-time virtualized guests. This is an area where hypervisor performance can make a big difference. KVM developers are actively looking at this with the real-time kernel and networking communities.
A: Brian:
Another challenge, I think, will be keeping up with where the Linux kernel is going. Linux is everywhere–cloud, servers, mobile–and virtualization has to follow. And as we move toward a hardware-oriented world like that described in the Internet of Things, KVM will need to adapt to that sector as well.
