Oracle 'Losing Patience' with XenSource, VMware 165
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."
Compromise (Score:4, Insightful)
Seriously people, this is computer software we're talking about, not Israel and Hezbollah. I think they can come to a compromise pretty soon here.
Of course.... (Score:3, Insightful)
Re:Compromise (Score:5, Insightful)
Impatience is a Virtue (Score:4, Insightful)
Re:Who cares. (Score:2, Insightful)
If you had bothered to RTA, you'd have seen that, evidently:
The article also mentions the Oracle Cluster File System technology (Open Source), as well as Oracle's recent acquisition of open-source database company Sleepycat and its Berkeley DB product earlier this year.
This may explain why I got a call recently from an Oracle rep, talking about their db solutions. I sort of laughed, since I work for a small nonprofit organization, but she assured me that they did have solutions for small and medium-sized companies. I thanked her for her time without asking for more details, but perhaps this newly acquired Berkeley product was why my company was targeted as a potential customer.
Right tool... (Score:2, Insightful)
Your type of attitude is just as stifling as proprietary offerings..."If your not open, then you are evil and must be destroyed. I'm taking my source and going home"
I'll play a risky card here. I see the value of open source and support it, but that doesn't mean it has to be the only game in town. Same thing with democracy. It is a superior gov't. However, does that mean we should crush all gov'ts that aren't democratic? I know a stretch, but the same principle applies. We have to be able to coexist with things that don't share our exact same viewpoints. So, you don't have to willingly support closed programs, but fighting against them is just as counter productive as not helping at all.
Re:Who cares. (Score:3, Insightful)
Long history of wheel reinvention (Score:5, Insightful)
However, if there's anything we can learn from that, it's that sometimes there are benefits to re-inventing something that already exists, and in some cases may already seem to work okay. What seems like a complete waste of time to one person might create a result that's just different enough in some way to be really useful to somebody. (In the case of Linux, to a lot of us anyway, it was Unix but without the high cost and crappy licensing, and with the ability to see the source; hugely significant to some people but I'm sure it looked totally redundant to Unix people.)
Sometimes reinvention is necessary. You make a good point though, that there does seem to be a lot of it going on at any given time, and maybe that doesn't need to be the case here -- in any event, it seems like the reasons for taking parallel roads to the same place rather than working together should be carefully considered.
Re:Of course.... (Score:3, Insightful)
VMMs (Score:4, Insightful)
VMMs were created, in part because Operating Systems were unstable, incompatible, and often too big. Now we have all these VMMs that are unstable, incompatible, and trying to to more and more. So the question is:
(1) What has the VMM community learned from the OS community, and
(2) Why should I believe that we're going to get right this time?
Re:Impatience is a Virtue (Score:2, Insightful)
70% Insightful
20% Overrated
10% Flamebait
TrollMods can't agree on which way they prefer to deny the way incompatible SQL screws them. Sounds like competing DB astroturf teams.
Slashdot seems to have institutionalized the equation of "criticism = flamebait". If Mods had to write a reason why they downmodded, it might slow down the trolls among them, or just give MetaMods something to make their job easier.
Think Xorg vs. XFree. (Score:3, Insightful)
Re:Of course.... (Score:3, Insightful)
What? Nothing to do with interoperability? Xen and Vmware need to sit down & hammer out a shared API - but its nothing to do with interoperability?
Imagine if the first line of the TFA was:
Oracle is not the sort of company that cooporates well with others with regards to common APIs, etc. Why the hell should we take advice from them about this seriously?
Apples, Meet Oranges (Score:3, Insightful)
Actually, the guest OS can very much benefit from being cooperatively virtualized.
A lot of realtime code is run along side the kernel under a rudimentary hypervisor (Google for nanokernels, Adeos [gna.org] and RTLinux [tldp.org] do this sort of thing). In this very important case, it is usually quite a pain to require the OS to have to implement the infrastructure to support emulated devices when it could be using a hypercall infrastructure like Xen. The real potential isn't the gigabyte-sized general-purpose OS guests, it's the 40 kilobyte realtime handlers.
If you're running VMware to run some Windows terminals under a beefy Linux box, that's great. It's an important use case.
However, in addition to this, Xen caters to situations with tiny realtime handlers running along side the a larger interface OS. Little dedicated systems controlling things like Avionics, X-ray equipment, or tracking systems. Xen is an architecture for revolutionary new systems. VMware is a crutch to prop up existing systems, and VMI is designed to efficiently implement that crutch. I don't want to take away people's crutches, I just don't want to impede the revolution.
In my case, specifically, the combination of Xen, a SAN, and CLVM has been consistently less trouble, less management, and higher performance than anything we achieved with VMware. Considering my development partner is a VMware dealer, you can bet that we exhausted their possibilities before diving into Xen. The Xen architecture has simply been better for my purposes.
If you desire to have any real understanding of the issues, take a look at the VMI spec [vmware.com] and then the Xen Hypercall docs [cam.ac.uk]. Note the proliferation of x86 instructions and constructs in the former and the clean implementation of abstract interfaces in the latter.
VMware is designed to do literal translation of instructions that are pretty much architecture specific. This is because that is how they virtualize--by instruction trapping and translation. The VMI is effectively defined in terms of fencing off x86 specific instructions, memory management, and certain IO. The idea is that everything "dangerous" is trapped and emulated.
The Xen hypercall interface, on the other hand, is much clearer and targeted at actually developing towards it somewhere above a machine code level. Rather than just providing mitigation for basic instructions and processor architecture, Xen provides an hypercall layer and abstractions of pagetable maps / IO that are not nearly as architecture specific. In Xen, a single priviledged domain is allowed to do the dangerous stuff (think kernel-space / user-space split) and an efficient, set of interfaces is used to selectively provide those services to the subdomains.
Of course XenSource and VMware can't agree. VMware doesn't want to have to use abstractions when their selling point is sandboxing binaries. XenSource doesn't want to compromise a good architecture for hardware partitioning just so that a commerical vendor (with sharing issues) can implement a simple meat grinder to churn native code into sandboxed code backed by their clever emulated hardware devices.
Silly Historical Note: If you have enough history under your belt, the VMI might remind you of the architecture behind the Windows NT compatability layer to run NT code on the DEC Alpha processor. The Xen Hypercall system will likely remind you of the architecture of the kernel-space / user-space split among Unixes. If you recognize these, I'm sure you remember which one was a solid, successful product and which one was a buggy source of enterprise-level headaches.