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.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. There has been a lot of speculation about whether Xen is actually ready for prime time. Click here to read more. 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. Check out eWEEK.coms for the latest open-source news, reviews and analysis.
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."