Open Source and the "Xen" of Xen
July 12, 2007 
After my post two weeks ago about Xen, I got a call from the XenSource people. I had a long chat with their CTO Simon Crosby, who had some very interesting things to say.
He confirmed that XenSource has reached 500 customers, and added that they are doubling their customer base every quarter. Obviously this can't go on forever, but it looks like they are seeing a nice little exponential spurt of adoption. These are mostly mid-market customers, though they are starting to see a few site license deals. Crosby says Xen is being pulled into enterprise and production environments sooner than they expected. I suspect most of these larger deals are hosting-related in one way or another, such as the Amazon EC3 example, where Crosby says they have 3,000 servers under Xen.
Crosby also shed some light on the changes in XenSource's go-to-market strategy. A few years ago their plan was just to deliver the best hypervisor they could, and rely on the Linux distributors (Suse and Red Hat) to take it to market. But the results of this approach to date haven't been terribly exciting, so the new strategy is to sell a full-blown competitor to VMware's ESX, that is, the hypervisor plus the entire management and infrastructure framework. XenEnterprise 3.0, released last year, was the first big step in the implementation of this strategy. The next major milestone will be the release of XenEnterprise 4.0, set for later this summer.
One key point about XenSource that they don't go out of their way to emphasize is that their offering is a hybrid of open and closed source. The Xen hypervisor itself is GPLv2, while its system-level APIs come under a "BSD-like" license which is friendly to closed source OEM partners. But the XenEnterprise management tools which use those APIs – and which for evident marketing reasons they are calling XenCenter – are plain old commercial software. There's nothing wrong with that, of course – this company isn't exactly crushing anyone under its proprietary boot. Their reasoning is that if they released all of their stuff under GPL then Red Hat would just scoop it up and serve it in place of the very inferior management tools bundled into RHEL5.
The story behind the "BSD-like" license governing the Xen APIs is also interesting. According to Crosby, use of the Xen trademark (as distinct from the GPL code) is restricted to software developers who respect both the APIs and the ABI (application binary interface). This requirement has produced some friction with Red Hat, which as a result has stopped using the Xen trademark, leaving itself free to pursue what Crosby calls "proprietary software published openly," as exemplified by the libvirt API in RHEL5. Crosby argues that the ABI policy guarantees you can take a VM out of the freezer ten years from now and still be sure it will run on whatever version of Xen is current then. This isn't the way operating systems traditionally work, of course. You can't just take every application and driver that worked with Windows XP and expect it to work with Vista. But these days people use virtual machines as portable containers for their applications, so you need to be sure that new versions of the hypervisor won't break the ABI.
Interestingly, Crosby points out that the most common workloads running on VMs these days - regardless of the hypervisor used – are legacy versions of Windows, especially Windows 2000, because that's where the largest number of legacy apps have accumulated in customer data centers. By contrast, since the big growth in enterprise Linux has occurred only in the last few years, a higher proportion of Linux apps are running on more recent versions of the OS, and thus don't require as much VM-based "containerization."
There's a lot more to be said about the parallels between what XenSource is doing and the VMware approach. I'll try to cover some of these issues in my next post.
Copyright © 2007, Peerstone Research Inc. All rights reserved.
Reader Comments (9)
Surprise, Red Hat does not want to bear the burden of maintaining API/ABIs set in stone just because XenSource wants them to.
I suspect in ten years no one but XenSource will propose those ABIs, and they'll be irrelevant because the FLOSS Linux distributions will have moved forward too much.
Calling libvirt ""proprietary software published openly" is not
only disingenuous it's also patently false. Libvirt is LGPL'ed,
run as an open source project, and I suggest to see the AUTHORS
list to see the wide range of contributors. The point of libvirt
is to be able to develop applications for virtualization which
can use Xen but are not tied to the Xen release of the day, we
have QEmu and KVM support, OpenVZ is being worked on. This
is an open source project, change and development are discussed
completely publicly.
For more informations, check for yourself on libvirt.org web site.
Daniel Veillard, creator/maintainer of libvirt project
We're a growing hosting company using Xen.
We love the project, and feel the design is very advanced and is a very good fit for our application.
The XenSource economic model, however, appears to be hampering adoption from our point of view.
Xen is open source. We chose it *because* of that!
You'd *think* that XenSource would be interested in profiting from the open source project.
However, if you call for support, the salespeople literally spread FUD against the open source version in an attempt to get you to use the binary distro, which is all they will support.
Want to spend real money on support of the open sourced code?
You cannot do so at XenSource.
Weird!
Novell will support Xen as part of any SLES support package you enter into.
Just a couple of moderations, Jeff.
First, the XenSource model of mixed source is in part forced by the licenses of key components that we use, such as the Microsoft DDK, which requires that drivers developed using it, are not open sourced. XenSource's commitment to the community is that the core Xen engine is always the very best version of the hypervisor at all times. Every fix, every advancement that the community delivers, goes into the code base right away.
The project delivers an "engine" for virtualization, not a whole product. It does so specifically to endorse the business models of the value-added providers such as Red Hat, Novell and others, who add value to Xen, and deliver it to their customers. The project does not deliver a whole product, simply because it honours the value-add of the community vendors. So the "engine" approach is not "to stop Red Hat running away with all the value" but to "allow Red Hat to independently add value to the engine and deliver a differentiated product to its customers". That is an important distinction that your blog fails to communicate.
XenSource delivers a platform hypervisor into a market that is largely Windows based. That's just where we choose to play. Red Hat delivers an integrated hypervisor into an entirely open source market. There is no conflict, and that is good for Xen and for the vendors that deliver Xen into different markets. So it is fair to say that the engine approach is the correct one, in comparison say to the "fedora core as complete untouchable product" approach, which would probably alienate sectors of the community.
It's difficult to please everyone. The objective is to endorse, legitimize and encourage multiple vendors to deliver Xen to market, adding whatever value-added features they choose to. Red Hat's product is suited to a particular market, and I think that's great.
I personally think libvirt is a strange way to go, but that's not a project view, or a XenSource view. The XenAPI supports a much richer abstraction, is Xen version proof, and also supports the DMTF CIM standard for managment of virtualization. Those are all pluses as far as I can see. But libvirt is fine if you don't want a rich ecosystem of standards-based management products to just "snap in".
Best
Simon
RedHat's approach to management of the virtual enterprise uses their satellite product. The real management parts do not live on the individually managed nodes at all. Satellite version 5 was released as a beginning and will likely address most people's needs, the subsequent update will likely bridge the gap between the other products and tool sets.
That being said, it is not realistic to expect that customers or green technicians will use vendor supplied group-ware tools directly to manage products across a large complex enterprise...that is why we were given have APIs to the tool sets. I feel that libvirt and the Satellite APIs are just fine for us to do what we need to do in our enterprise. As a point of consideration, I doubt that Amazon uses any vendor provided front end for their customers with their elastic cloud.
As a suggestion, you might want to ask Novell and RedHat about their vision, especially around management of large virtual enterprises. I do not know this for a fact, but I suspect that Novell's answer would lie in ZenWorks.
FUD may get more hits, thus more revenue in the short term, but the long term implications of FUD may not bear as much fruit.
Good luck to you and good day.
The concept that something can be open source (even have several contributors) and still be prioritary is not a new claim made by XenSource. This has been brought up before back around 2000 by Caldera's Ransom Love. The idea is that there is FOSS projects that are not implementing a pre-existing standards. But in this case, I would take the claim that libvirt is "prioritary software published openly" as a badge of honor.
Companies like Microsoft, XenSource and DMTF seem to assume that their name alone is the only selling point needed for others to follow their "standards."
Simon points out that XenAPI is a richer abstraction that libvirt. However, libvirt is a middle-ware piece that abstracts not only between the top level program and the library but also provides enough abstraction to plug-in a different VM engine exists behind it. On the other hand, XenAPI current code is tightly integrated with the Xen engine. Instead of trying to "sell" XenAPI as a VM independent API, the work of centralizing Xen specific calls is left up to developers external to XenSource. Based on this, there is less "cost" in creating new abstraction system from scratch where the VM specifics are centralized as an initial design goal than re-work the existing code.
DMTF is even worse when it comes to "selling" themselves as being a group worth listening too. They claim to have the backing of Microsoft while at the same time Microsoft implements alternatives to SLP instead of following the specs of the SMTF. The DMTF's WBEM is even more complex than UPnP thus pushing yet another security nightmare as a "standard." And then there is CIM--the DMTF website is quick to point out that they have "free" tools and open source for implementing CIM. But the truth comes out when attempting to actually download the tools and open source. The DMTF equires a membership which for most of the FOSS community would cost $200 per independent developer! So, to me, supporting DMTF CIM is a strange way to go. Note that all the open source code on the libvirt website is **truely** free and the XML schema is easy to understand.
What bothers me most about XenSource is the way they have sold out to Microsoft. I'm not looking just for a VM engine for servers but also for workstations as well. Personally, I see VMs at the workstation as one method of acknowledging the growing problem of keeping data confidential. I see the direction that RH and libvirt is headed in as working towards that goal. On the other hand, I see Xen's partnership with a company that has started a trend of EULAs that deny use of VMs as being a major issue. That XenSource can still claim to be a "partner" and remain silent about what Microsoft is doing seems to me to be in conflict with the direction I want to go.
Thanks to Simon Crosby for his response to Jeff's article. I have put a link on Interop News to Simon's blog entry on the topic:
http://www.interopnews.com/news/xen-and-the-art-of-being-slashdotted.html.
Is there any news on IF and WHEN Sparc processor support might make it into Xen. I heard Sun were doing some work here but have heard nothing since.