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.
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."
I think the problem was that Xen source was pushing a design that was exclusive to Xen, no other hypervisor could use it's option. VMware, Microsoft, wouldn't be able to use it, it would be custom just to Xen. I guess that you maybe think that the kernel should have 50 or so different hypervisor product specific interface is a better solution than a generalized hypervisor.
+ for+Linux/2100-7344_3-6061019.html
In addition to the topic links here's another.
http://news.com.com/VMware-friendly+change+likely
The Reg is leading with a story putting meat on the bones of the contention in the article that Xen is *not ready for prime-time*.
It will be interesting to see who's chumming, who's fishing and who's cutting bait when this boat comes in. Is it possible VMWare is trolling Oracle for an offer, playing hardball like this?
illegitimii non ingravare
I read 'offline meditation'. But then, maybe that's exactly what they need.
Defining Statistics and Social Research
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.
Honestly, XenSource seems to be taking much more of a "my way or the highway" approach, which is bizarre since their data center market penetration is about nil. Well, in a couple of years, when Microsoft discards them like a used kleenex, they'll hopefully learn. I hope it doesn't take that long.
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."
Simon can complain all he wants, but we've had profound difficulties making their virtualization scheme work. It looks so tasty on paper, and yet Xen-modified kernels are unstable and feeble.
The VMWare pressure, however, doesn't help. EMC/VMWare has a killer cadre of coders. They're very good and well paid, and can shift quickly to keep ahead of the market. Yes, it's largely NOT free open source software. Ok, it's free in some cases, but not OSS.
Am I asking them not to beat up on Xen? Yes. It still needs to cook before it's going to be ready for prime time use. Until then, it's premature.
---- Teach Peace. It's Cheaper Than War.
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
Actually VMware suggested a documented, standardized, gernal interface that would allow closed-source binaries to talk to it. Xen want's an interface that is specific to Xen, that only Xen could use, effectively closing VMware and anyone else who would want to do virtualization that is any different than Xen from being in the kernel. If you believe that nobody could ever create a product better than Xen or if you believe that Xen will always have all the possible features that you could ever want in a hypervisor than you should support Xen specific patches in the kernel rather than a general interface.
One that was set on HARDWARE instead, a virtualization support at processor level?
Correct me if I'm wrong, but doesn't both Intel and AMD has develloped something (http://en.wikipedia.org/wiki/Vanderpool) that will make it possible to run unmodified guest OSes under the same supervisor? If so, why bother with a common interface to the Linux Kernel, if this interface won't be necessary?
It would be much better if they focused on supporting each other VM image format, so one could migrate a live Xen Domain to a VMWare server and vice-versa.
---- You know how some doctors have the Messiah complex - they need to save the world? You've got the "Rubik's" complex
The Xen hypervisor interface already is a virtual abstraction. If vmware wants to implement new things, they can provide feature additions to the interface without making an incompatible interface. What vmware wants is like overriding the vfs layer with another vfs layer so that they can port their own filesystem to it easily, and they want it included in the kernel as the method other fs players have to use.
vmware has set back virtualization. Morton admitted himself that he didn't know how it all worked.
Yeah, what teh_crizzle said. Xen is harder to set up, but also doable without wrecking your install. The thing about Xen is, it works by modifying the kernel, so any linux installation media needs a modified kernel to install into Xen. But Xen is faster on any processor that doesn't have built in virtualization. On the other hand, VMWare is much easier to use, so if you want to use virtualization for playing around with new distros, VMware is your best bet.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
No, it does not.
/var/vmware/) and you're pretty much off. It took me longer and was more of a PITA to install Windows on the resulting VM than it was to install VMWare itself.
I've set up VMWare Server (which is FAIB) on my Kubuntu Dapper system and it was quite easy. Basically you just follow the instructions, I didn't run into any major installation gotchas. You register with VMWare and they email you a serial number and a link to the download site; you run the installer and choose where you want things to be installed (I use
Only thing I ran into though: be careful of the networking option that you choose. The default is 'Bridged,' which creates a virtual interface using your machine's same network card, which then gets a DHCP address from your LAN router. This is nice because it means your virtual machine doesn't use the same IP as your host machine's native OS. This caused me some problems with services that I had running on the host, netatalk in particular. (The default configuration of netatalk is to try to automatically find the correct network interface, and it got confused by the virtual one apparently; explicitly defining which one to use solved the problem.)
Long story short: consider using the 'NAT' networking option until you know what you're doing; this does IP masquerading so that the VM uses your machine's regular network interface and IP address. It means there's an extra layer of NAT to punch through if you wanted to run services on the VM, but it keeps most of the complexity hidden inside VMWare.
After you get VMWare installed, you can either create a bare virtual hard disk and install whichever x86 OS you want, or you can download pre-configured virtual machines; I don't know if Edgy is one of these, but it might be.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
You're kidding, right? This is computer software, the battleground of OCPD personalities, where one aspect is taken out of context and used to judge something into "perfect" and "complete evil" categories, with no middle ground. And then proceed to try to raise a crusade to death against the complete evil ones. It's the place where vi vs emacs, KDE vs Gnome, Java vs C++, Intel vs AMD, goto vs for/while loops, and of course OSS vs anything else isn't just worth a debate, but become religious wars and things to fight to death for or against.
I bet that when your stereotypical ultra-militant extremist-Islamist organization's meetings go out of hands, someone could interject "stop it guys, you're starting to sound like on the OpenBSD mailing lists." And, assuming they've even heard of OpenBSD, the previously screaming and fist-shaking speakers would blush and start staring at their own shoes in silence.
In fact, if the Hesbolah vs Israel _were_ like the software holy wars, God help us, because there's be no possibility of peace ever. I could just see a peace talks turning into "ok, you may have aggreed to free Palestine, pay reparations, change your language to Arabic, convert to Islamic faith, recognize the Ayatolah's authority and everything... but... YOU RUN YOUR SERVERS ON WINDOWS! DIE INFIDEL!!!"
A polar bear is a cartesian bear after a coordinate transform.
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. 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.
Xen wants VMware to adopt the Xen hypervisor interface. 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.
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, thankfully, someone else is doing instead, with paravirt_ops).
Finally: I saw more pot-shots about being unable to benchmark VMware in the original article. That changed several months ago, benchmarks are now allowed by EULA. Certain companies ought to stop spreading FUD...
A witty [sig] proves nothing. --Voltaire
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)