eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Oracle is fast losing its patience with both XenSource and VMware over their reluctance to work together to help develop a single interface that will integrate a variety of virtualization solutions in the Linux kernel.
“We certainly believe in one simple universal way to integrate a variety of virtualization solutions, and that is the way that Andrew Morton [the maintainer of the stable Linux kernel] wants to go,” said Bob Shimp, the vice president of Oracles technology business unit, on July 31.
“I can say that Oracle is losing its patience over this issue and we are going to be pushing harder and harder on everybody to come to the table with a realistic solution,” he said, noting that it is in everyones interest to get a solution thrashed out that benefits the open-source community as a whole.
Oracle is a significant player in the open-source community and, as both an open-source and commercial database provider, has a very strong interest in getting virtualization technology into the kernel.
It recently successfully managed to get the Oracle Cluster File System technology, an open standard file system, adopted as part of the Linux 2.6 kernel, the first such technology to be included in the kernel.
It also acquired open-source database company Sleepycat and its Berkeley DB product earlier this year.
That acquisition helped Oracle reach smaller customers it may not have been able to before, Shimp said.
Oracles comments come hot on the heels of those made by Greg Kroah-Hartman, a Linux kernel maintainer for a number of subsystems and a maintainer of the stable Linux kernel team, on July 26 at the annual OSCON (OReilly Open Source Conference) in Portland, Ore.
Kroah-Hartman said then that XenSource and VMware were butting heads instead of working together to come up with a joint solution.
“Xen and VMware both supply huge patch-sets and are both trying to do the same thing, but their technologies dont work with one another, and we are telling them that we do not want to take one over the other, we want them to talk and work it out,” he said.
Getting the two companies to talk to one another and work together has been requiring mediation by neutral parties, including people from the Linux distributions, the community and vendors, he said, adding that these mediators “are currently trying to kick them in the butt and get them to work together. So that solution is not coming anytime soon,” Kroah-Hartman said.
Plans to Merge
The initial plan was to merge the Xen patches into the Linux kernel, which would then have only run on Xen, but there has been a move away from that toward an interface in the kernel that would let it work with any virtualization hypervisor technology. Xen, VMware and Microsoft are all working on hypervisor technologies.
While Brian Byun, the vice president of products and alliances for VMware, acknowledged that the Palo Alto, Calif.-headquartered company had been approached by a neutral third party about offline mediation to establish how best to make this happen, he said he was unaware of any previous request for the company to meet directly with XenSource on this.
“We are very supportive of the mediation request, but we have not, as yet, had a request from Oracle – with whom we work closely–to mediate in this regard. We would love nothing more than a standard, multi-party approach to achieving this for the Linux kernel as soon as possible. We want something to be established quickly so we can move forward from there,” Byun said.
In fact, Byun recently wrote on his blog about Linux hypervisor interoperability and standards, which was also a response to the news that Microsoft and XenSource had agreed to work together on an interoperability solution.
In that blog post, Byun said that VMware hopes there will soon be a standard Linux interface for para-virtualization, which would simplify and standardize how Linux is supported on various hypervisors, including VMware and Xen.
“VMware is actively working with the Linux kernel community to develop an open interface so that the Linux kernel can run natively and efficiently on a choice of hypervisors. Such an interface would also be available to any operating system,” he said.
VMware has made its initial proposal for such an interface available to the Linux community and is pursuing Linux and hypervisor interoperability, not as a commercial arrangement, but within the open, transparent and merit-based multi-vendor approach, he said.
While Byun stressed the fact that VMware has been working closely with the Linux kernel community with regard to the proposed Linux virtualization interface in his July 31 interview with eWEEK, he did acknowledge that its proposal is different to that which XenSource has implemented.
“We have told the kernel community exactly what our proposal is and what the characteristics we believe a solution has to have for the Linux maintainers and customers, for instance avoiding strict coupling between the kernel and the hypervisor because that is more maintainable for customers and the Linux distributions,” he said.
Discussions
But VMware was not keen on meeting directly with XenSource, as it believed there should be multi-party discussions around the best solution for a common Linux virtualization interface, and that those discussions should take place in an open forum like the kernel mailing list.
“That is more productive than a backroom, one-to-one discussion between two commercial companies,” he said.
For his part, Simon Crosby, the CTO for XenSource, said that while there had historically been a “degree of head butting, we are well beyond that now.”
But he rules out any mediation, saying that this is “not an issue at this stage, as it is not about marketing or a public fight. Everything Ive seen on the part of the engineering teams of both companies indicates a commitment to solving real technical issues,” he told eWEEK in an interview.
Both companies have benefited tremendously from the proposals of IBM and other vendors who have a clear interest in a broadly available, common hypercall API (Application Program Interface).
“Our community and ecosystem has no interest in a cock-fight with VMware; on the contrary, our market and customers will benefit significantly from the exact opposite: best of breed, interoperable products,” he said.
The essential difference between the two is that the Virtual Machine Interface proposal from VMware basically allowed it to hook the hypervisor into the kernel at load time, without ever needing to expose the hypercall API itself, or any of their closed source code.
“Its an ABI [Application Binary Interface] rather than an API. It has some nice technical properties, in particular with regard to enabling the same kernel to run virtualized or native. Xen supports this too, but through a different mechanism, in which the kernel either links with Xen or with a shim (that offers the same hypercall API) that allows the kernel to run native,” he said.
In contrast, Xen used an open API, which allowed the kernel developers to see and work with the code that will virtualize the kernel.
Since some of the most performance-critical code, like page table management, occur in the hypervisor; having an API is advantageous in that the kernel code and hypervisor can evolve together into the future, and the kernel community could improve both the hypervisor and Xen itself, Crosby said.
“Both proposals have merits. IBM made a key contribution in their proposed paravirt-ops interface, which will accommodate both methods. Its simple, elegant, and now the issue is down to engineers to find the best compromise,” he said.
It has also been difficult to achieve interoperability due the fact that VMware had not yet committed to delivery of a product that supported paravirtualization, so it was still impossible to test their proposed interface on a real hypervisor, Crosby said.
Also the inability to publish performance benchmarks for VMware products made it difficult to pick the highest performing alternative, and left the community having to design open-source code to interface to a “binary blob” of a closed source hypervisor.
But, given that this was the first time that the kernel community had considered actively accommodating a closed source binary in the Linux kernel, “it poses significant technical challenges as well as a semi-religious issue about closed/open source. But we believe that there has been tremendous progress, particularly over the last couple of months,” he said.
Until the recent 2006 Linux Symposium, it also had not been clear what the kernel communitys preferred architectural approach was for inclusion of paravirtualization, Crosby said.
“We were pleased to see the issue raised at the kernel summit, where both the Xen interface and the VMware proposal were discussed, and a decision taken on a preferred path toward inclusion. The net result was the adoption of key elements of an interface proposed by IBM, that will provide the openness and performance required by Xen, and accommodate VMwares closed-source hypercall API,” he said.
Since then, patches had been submitted at a high rate, and XenSources engineers were working closely with VMware engineers on all aspects of the implementation.
“The VMware team should be praised for engaging an open dialog with the Linux kernel and Xen communities, and they are actively engaging in the process,” he said.