Where will the Xen.org community take Xen 4.0?

The Xen community launched Xen 3.4 back in May of this year.  The release added quite a few new features, chief among them being support for the Microsoft Hyper-V enlightenment interface, power management, CPU and memory offlining, and device pass-through improvements.  A short time later, the community released Version 3.4.1, a maintenance release.

We can expect to see a series of quick dot releases like this in the future.  Community leaders said that rather than focus on the “big bang” 12-month development cycle, as they did with Xen 1.0, 2.0, and 3.0, the group plans on releasing updates in a far more incremental process.  The group’s goal is to go through a stabilization phase first, and then come out with point releases every 10-12 weeks.  Much like with Linux, these point releases will be maintained with bug fixes until the next point release.

[ Got a Xen hypervisor question? This community guide may have the answers you need | And keep up with the latest virtualization news with InfoWorld’s virtualization newsletter and visit the InfoWorld Virtualization Topic Center for news, blogs, essentials, and information about InfoWorld virtualization events. ]

As the community continues to advance Xen 3.x, they are also looking to the future with added support coming from the community.  Xen community leaders asked for feature requests, and community members answered.  Looking at the Xen proposed road map for 4.0 gives us a few glimpses into what people are asking for with future releases.  They are asking for some interesting things, such as:

• RDMA Live Migration Support to allow for faster and smoother live migration when using Infiniband or Iwarp NICs
• Working toward stable support for passing through USB controllers/devices and PCI devices for paravirtualized guests
• Fault tolerance with Project Remus and Kemari
• Configure a Virtual Bridge like a real switch (e.g. Control VLAN, port status, etc.)
• VLAN tagging per NIC in the VM Configuration File
• Creating a virtual Ethernet switch, virtual uplinks (through SSH, for example), virtual cables, virtual plugs to create a virtual switch per client
• Limit I/O for individual disks of VM (similar to credit scheduler weight)
• Dynamic Memory Management for Overcommitting RAM
• PCI CGA Pass through for VT-d (vendor cards like NVIDIA, ATI, etc.)
• Online resizing of DomU Disks

And if you want to learn about more ideas on where Xen could be headed, check out some of the new project ideas submitted by other Xen community members that Ian Pratt, chief architect of the Xen project and chairman of Xen.org, found interesting:

• Build on some of the existing work done in Cambridge to use Tungsten Graphics Gallium as a device-independent and API-independent 3D remoting protocol.
• Xen will soon be including the open flow vswitch developed under the openvswitch.org project.  In order to integrate support for SR-IOV network hardware, we need a special kind of bond driver in the guest that initially routes traffic via the vswitch, but then can receive instructions from the vswitch to route individual flows to the direct hardware path (falling back to the normal software path via the vswitch if the SR-IOV VF gets unplugged).
• Fully implement domain0 restartability, effectively enabling a dom0 reboot or upgrade without rebooting the rest of the system.
• Investigate how a hypervisor could best use large amounts of NAND FLASH memory (not just via a disk API, but as native FLASH).
• Deterministic replay for Xen
• And more.

What about you?  Do you have any ideas that you’d like to share for the Xen 4.0 road map?  It’s easy.  Just submit your ideas to the xen-devel mailing list.