Slashdot Mirror
Oracle 'Losing Patience' with XenSource, VMware
HiTech writes "eWeek has an article looking at Oracle's frustration with both XenSource and VMware over their reluctance to work together. The goal is to develop a single interface for virtualization solutions in the Linux kernel. Oracle's comments follow those by Linux kernel maintainer Greg Kroah-Hartman at Oscon last week that XenSource and VMware were butting heads instead of working together to come up with a joint solution. Brian Byun, VMware's vice president of products and alliances, admits the company had been approached by a neutral third party for offline mediation to establish how best to make this happen. But Simon Crosby, the CTO for XenSource, rules out any mediation, saying he believes the two companies are committed to solving the real technical issues."
VMWare has a business to protect. XenSource does not.
Ahem... "XenSource plays the dual role of leading the open source Xen(TM) community, while simultaneously selling value-added enterprise solutions based on Xen technology. [...] XenSource is backed by leading venture capital firms, including Kleiner Perkins Caufield & Byers, Sevin Rosen Funds, Accel Partners, and New Enterprise Associates."
Good point, you are right and newer processors, both Intel and AMD, support virtualization natively. With one of these processors, you can run Windows under Xen. The common interface is needed because 99.5% of processors out there do not support native virtualization.
And if you think getting them to agree on a Linux kernel interface is hard, just try getting them to agree to a common image format. It's not gonna happen.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Disclaimer: VMware employee, personal opinion.
:-) Didn't think it was necessary to mention but what the heck :-)
:-) The problem with a VC-funded company associated with Xen is that some brand new executive makes some silly statement and it's treated as the official opinion of the Xen community.
:-)
;-)), VMI would already be in the kernel.
Disclaimer: Xen hacker, personal opinion
VMware went to OLS and presented a paper demonstrating a VMI interface that runs either Xen or VMware at the same speed as the Xen interface.
I missed OLS unfortunately but I've come to the conclusion that VMI is not the best interface for Xen long term. I should say that I was advocating VMI for a long time previously so this isn't just a knee-jerk reaction.
The problem with VMI is that it hides the hypervisor interface from the guest. Now, if you're VMware, this is ideal. If you're a Free Software project, and your interfaces are evolving overtime, having your interfaces hidden means that there's no pressure to improve them.
The biggest benefit for upstream merge for Xen will be a ton of hackers on LKML auditing the interfaces and saying where they suck and forcing us to change them. You don't want to hide the virtual timer interface behind PIT emulation. You want codesign.
This doesn't mean that Linux shouldn't support VMI. It just means that not all projects should standardize on the VMI ABI.
Xen has never tried to run on a VMware hypervisor, but XenSource went and signed a deal to run on the (future) Windows hypervisor. My opinion is that Xen is a bunch of hypocrites: they complain about how VMware isn't open, then go sign a deal with the least open company of all. Of course, I'm biased.
Please try to separate XenSource from the Xen community. Many of us don't work for XenSource and many of us think that XenSource does stupid things (this being a good example).
Xen wants VMware to adopt the Xen hypervisor interface.
Many of us don't even want Xen to use its own interface. Why would we wish it upon VMware
Imagine if every exec at every company loosely associated with Linux was quoted as gospel for Linux's future.
This is impossible. The Xen interface is too tightly coupled to the Xen hypervisor; it's missing pieces that are necessary to run the VMware hypervisor at reasonable performance. VMware doesn't really care which interface actually proliferates (as in, there will be a layer of interface glue regardless), so long as the interface is good enough. Xen's interface is not good enough. As of two weeks ago, Xen and VMI were the only two interfaces out there.
This is absolutely correct. The Xen interface is not rich enough to support a variety of hypervisors with reasonable performance. Anyone who claims differently is lying to you
Greg K-H's gripe with VMware is that the kernel module isn't open source. Yes and no (I don't want to argue - the code is open but not GPLed), the point is that he's spending more time complaining about Xen and VMware than it would take to actually mediate the problem.
Which is a valid gripe. VMware is going to get the short-end of the stick when interacting with the kernel community because they are doing something that is viewed both as immoral and illegal. There's an easy way to fix that...
Honestly, if there was a single Free hypervisor that worked with VMI (and L4 doesn't count
(Which, thankfully, someone else is doing instead, with paravirt_ops).
Yes, and this is going to be a very long process. I will say too that engineers from Xen and VMware have both been working together surprisingly well on this. There is an active conversation going on in the osdl-virtualization list and on other channels. Despite these stories, Xen and VMware are actually working together.
Finally: I saw more pot-shots about being unable to benc