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."
Getting the two companies to talk to one another and work together has been requiring mediation by neutral parties
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.
Oracle's interoperability with competing products is perfect. Yeesh.
There are shills on slashdot. Apparently, I'm one of them.
I wish someone would get Xen and VMWare to work together for a single virtualization interface. Then they might be able to talk some sense into Oracle so there's a single SQL interface regardless of which SQL vendor or server or version or driver or language or OS...
--
make install -not war
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.
[[Jdapnc. O,..y (Nuts...keyboard stuck in Dvorak mode again.)
Then YOU don't use them...I understand your feelings about open-source, but how does that statement get modded interesting?
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.
When I have a kid, I want to put him in one of those strollers for twins and then run around the mall looking frantic.
I'm loosing patience with propriatary software vendors who embrace doing the minimal amount of free software necissary to hold back free alternatives. They're getting washed over, and they deserve every bit of it.
Well, that's kind of to be expected: when you get right down to it, the whole premise of Linux was a reinvention of the wheel. It's a clone of an operating system that already existed -- it doesn't get much more re-inventive than that.
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.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
I'll re-ask the question I asked the panel at VEE this year:
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?
no comment
All in all, OSS allows for a number of companies to move quickly by working together. But once a company or group wants to control it in an irresonible fashion, then it allows for it to be forked and done up right. XFree86 vs. Xorg is the best example of this. XenSource is a start-up based around Xen. But they do not have to be the only player. All it takes is another company to start-up and work with VmWare to create an interface and then mod Xen to it.
I prefer the "u" in honour as it seems to be missing these days.
Disclaimer: In addition to being opinionated, I've used Xen and VMware in an attempt to deploy an ISP hosting environment.
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 and RTLinux 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 and then the Xen Hypercall docs. 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.
I think Mauve has the most RAM. --PHB (Dilbert Comic)