Opening Up XenServer – Reworking XenIface.sys

When we first began to discuss the specifics of open sourcing XenServer I had to raise my hand and say “No”.  Not because I didn’t want the software to be opened up, but because I knew that one of the modules I look after (XenIface.sys – the XenServer Windows PV Interface driver) had code in it which we wouldn’t be allowed to ship under an open source licence (we could ship the bainaries – we could even give away the source code, but we couldn’t let other people give that code away).  We had to come up with a new plan.  And the plan that was agreed on was the one I suggested:

The interesting bits of XenIface are in files which we unambiguously own.  But there is no chance we will ever get the right to give the rest away.  Nor is there any chance of us having the time to rewrite that code by the date XenServer goes open source.  So what we can do is just put the files we own out into the world, and rewrite the rest in our own time.

This was a dangerous plan.  Specifically because I know how corporations work, and once the buzz of hitting the ‘We’ve open sourced everything’ has passed, people will want new features, not just rewrites of perfectly functional code.  It would be too easy for things to get missed.

The last couple of weeks have seen a lot of excitement.  We opened up (most of) the code.  The XenServer team all gathered in a kitchen at work to drink Champagne and celebrate.  There was also the release of Citrix XenServer 6.2 accompanying the open sourcing.  And (on the Windows team at least) we started our new development processes with all the code changes happening out in the open, going via GitHub.

But behind the scenes, I’ve been getting some programming done too.  Specifically, I managed to find the time (quite where from I’m not sure) to rework XenIface, strip it of the code we don’t own and get it working again.  The way I did this was quite simple:  I ripped the bottom end of the XenVif driver, pulled out all the networking and providing-PDOs-for-NDIS-drivers-to-attach-to code, and then plumbed in the remaining parts of XenIface.

The code isn’t quite ready for public consumption yet but:

It installs, enables, disables and uninstalls nicely

It passes our dev tests (which we use to ensure the WMI and IOCTL interfaces don’t change)

It has passes the HCK successfully (once I found the filter for something I was pretty sure was an HCK bug and persuaded it to install)


This is all, primarily, testament to the quality of the XenVif code which was so easy to pull apart and put into the XenIface driver.

Before we put it out in the world, I just want to prove that our internal system testing won’t show up any regressions – but I think we’re likely to be safe, as the changes to the code which provide the functionality have been very minor.

I wasn’t really expecting to see this code finished for another month or two (and was quite scared it would never happen at all).  Instead it looks like it’ll be out the door well ahead of schedule.  And once XenIface is in place, thats the complete driver set needed to let you run the Guest Agent and have the full PV tools optimised Windows guest experience.


It would just be nice if it was easy to install.


The good news there is that the installer package – which is the final missing part of the PV tools is also close to being releasable.  We didn’t ship that because we didn’t have confidence that the click through licence it displays was the right thing to display.  Well, I’ve finally had word back from legal about what we should be displaying and so there is only a bit of plumbing to do before that can be put up in all of its glory too.

You must be logged in to post a comment.