Despite the wide and good success the Xen hypervisor project has obtained in the open source community, commercial solutions based on it or incorporating it didn't have similar luck:

• the launch of Novell SUSE Linux Enterprise 10 has been severely judged by Red Hat, accusing the competitor to offer the product while still unsuitable for enterprise deployment
• the interoperability agreement between XenSource and Microsoft has been hit as well by VMware, accusing competitors to take advantage from open source community work without providing anything back
• and finally the launch of XenEnteprise, by XenSource itself, has been compromised by its own CEO's declarations, stating Xen actually isn't enterprise-ready

In this very confused scenario the most direct XenSource competitor, Virtual Iron, which is going to deliver a virtualization product based on Xen as well, decided to talk with virtualization.info: Mike Grandinetti, Chief Marketing Officer, offers company's point of view on Xen maturity, Red Hat involvement in the project, value of XenSource agreement with Microsoft and VMware future.

virtualization.info: Mike first of all thanks for joining virtualization.info and provide readers another perspective on this controversy. Explain Virtual Iron’s level of involvement in the Xen project, and how long the company has been working on the project.

Mike Grandinetti: Virtual Iron has been involved with the open source project for close to a year. We started contributing suggestions and code to the project in early 2006 with the goal of making Xen enterprise ready; i.e. hardening the hypervisor, improving reliability and scalability, increasing I/O efficiency and supporting enterprise-class workloads. Most importantly, we’ve enabled the hardware-assist capabilities provided on the latest generation Intel and AMD platforms which facilitate the support of unmodified 32 and 64 bit Linux and Windows operating systems.

We've contributed and continue to contribute our development efforts to the project. We've also spent a lot of time working with other core members of the Xen community – AMD, HP, IBM, Intel, Novell and Unisys - to understand their interest and needs and to validate our architectural approach and product design. To date, we would estimate that Virtual Iron has invested over 400 man months turning Xen from a project into a product.

VI: Some suppose Red Hat simply wasn’t able to deliver Xen within its own distribution in time for competing with Novell because they didn’t contribute to the project in the time originally planned. Can you tell us how much Red Hat has been active in the development of the hypervisor in the last year?

MG: Like Novell, Red Hat has been involved with the Xen project since its inception 3 years ago. However, it would appear that Red Hat is behind Novell in their Xen development efforts. Like most of the early Xen community, including Virtual Iron, Red Hat believed that the Xen project was more mature and professionally developed than what turned out to be the case.

Red Hat claims to have a small army of developers working on this project. However, it’s unclear to us why they have not been able to make more progress. Integrating Xen into RHEL may have proven to be more difficult than first estimated as they have yet to deliver a single OS paravirtualized on Xen, including their own upcoming RHEL 5 distribution.
Perhaps paravirtualization as an approach is too engineering-intensive in this rapidly evolving virtualization market. For example, with a measurably smaller team, working in a much tighter time frame, Virtual Iron has been able to deliver six unmodified OSs (both Linux and Windows) natively virtualized on top of our Xen-based virtualization platform to our early evaluation customers.

VI: In its last externalization, Red Hat accused Novell of not being responsible in delivering the product so early, compromising customers’ experience. What’s your take on this? Novell embedded the product too fast?

MG: Novell has always been about being first to market with their Linux distribution. Once again, they’ve pushed the envelope in their support for this specific capability and must feel their version of SLES is ready for their target customer. We applaud their efforts.

VI: Since the release of Virtual Iron 3 will base its own solution on Xen, what is the company’s position about Xen maturity? And mostly: why Xen is not ready? Where the problem lies?

MG: Xen, as an open source project, will never be enterprise-ready. That is the nature of open source. It’s the value that each vendor adds that makes the difference between a real product ready for production deployment and an open source project; between enterprise-ready and unstable.

Initially, some vendors thought that they could just take finished code from the Xen open source project and wrap it into their offerings. They were not prepared to make a significant development effort into the virtualization services layer or the virtual infrastructure management layer required to deliver an enterprise-ready product. These vendors dramatically underestimated what Xen was and what it wasn’t. In addition, they’ve come to appreciate just how complex virtualization software really is and the gaps between Xen the science project and a Xen-based solution that is ready for enterprise deployment.

As a focused virtualization solution provider, Virtual Iron's approach has been much more ambitious. We set out from the beginning to build an enterprise-ready virtualization solution on top of the Xen hypervisor and we brought a core competency in virtualization architecture and software development to the task. First we identified the gaps between what was in the project, and what we needed in it to deliver an enterprise-class solution. We worked closely with core members of the Xen development community – companies like AMD, HP, IBM, Intel, Novell and Unisys – and developed an architecture and robust code to support an enterprise-class solution. Virtual Iron extended the capabilities of Xen by building its own virtualization services and management layer on top of the Xen hypervisor. It’s now being evaluated at both end-user customer and strategic partner sites and is supporting enterprise-class workloads. We've attempted to contribute a lot of this code back to the open source Xen project because we want the user community to get these same benefits. This was a substantial development effort and it’s what really makes the difference between a Xen-based virtualization solution that’s enterprise-ready and those that are not.

Virtual Iron feels we have a version of Xen that is ready for evaluation as an Enterprise Data Center Virtualization platform. We think the difference is all in one’s market focus.

VI: Another point of interest lately has been the XenSource agreement with Microsoft for providing interoperability between XenEnterprise and upcoming Windows Server Virtualization. VMware severely criticized the move denouncing damage against open source community and the Xen project itself. What is the Virtual Iron position on this?

MG: It is great that Microsoft has embraced future paravirtualized Linux OS’s running on their future Windows hypervisor and hopefully the entire community will benefit from this expansion of the Xen project. It would be a huge red flag for the Xen project if this turns out to be a proprietary-only use of Xen.

However, many within the Xen community question the motives of XenSource:

• are they building a one-lane toll bridge between paravirtualized Xen Linux and the Windows hypervisor?
• is XenSource going to charge the Linux distributors to be able to run on the future Windows hypervisor platforms?
• is this similar in philosophy to XenSource’s recently announced Xen Certification of the community project?
• how do you certify a community project unless the real motivation is to leverage an open source community for commercial gains at the expense of the community? Only time will tell if this is a real open source project in the image of Linux or just another proprietary project cloaked in open source clothing.

VI: What does the future hold for VMware?

MG: We don't know exactly, but we can make some educated guesses based on the software industry's Darwinian history. For example, in the x86 server OS space, many different OSs have been squeezed out by Microsoft and the many different flavors of (Open Source) Linux. We expect a similar dynamic to occur in the server virtualization market over time. Longer term, it's not inconceivable that the VMware hypervisor is squeezed out of the market as this layer of the virtualization stack becomes increasingly commoditized and ubiquitous. Specifically, we believe that only two hypervisors will survive - proprietary (Microsoft) and open source (Xen-based). Only Microsoft is capable of sustaining the proprietary development efforts required. Open source represents the future of software development and is the only sustainable alternative to large-scale proprietary efforts.

From a business perspective, VMware has limited strategic choices as its ownership by EMC will put them increasingly at odds with their strategic partners. This is specifically why the Xen ecosystem emerged to begin with. In addition, Wall Street continues to question whether EMC will really invest in growing this business with complementary acquisitions, as it is not mainstream to their core business.

From a technology perspective, VMware's architecture is an eight year old, legacy way to virtualize the x86 architecture. Its approach will face continued challenges now that new hardware-assisted virtualization processors from AMD and Intel are shipping.