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.
VMWare and Oracle are both proprietary.
Oracle's interoperability with competing products is perfect. Yeesh.
There are shills on slashdot. Apparently, I'm one of them.
VMWare has a business to protect. XenSource does not. Clearly we need to go with XenSource's design, as their primary focus (like all open source programmers) is in producing perfect software. VMWare has a business to protect, so why should we listen to what they want? Business will come if the design is thorough. No need to have people upgrade eight times for "features" that should have been there in the first place. So in short, nobody cares what VMWare wants.
Oracle is the stately old dog, while XenSource is the yappy pup who circles him constantly.
If there's a more apt comparison, I don't want to know about it.
what a surprise?
from previous post: many demand corepirate nazi execrable stop abusing US
we the peepoles?
how is it allowed? just like corn passing through a bird's butt eye gas.
all they (the felonious nazi execrable) want is... everything. at what cost to US?
lookout bullow.
for many of US, the only way out is up.
don't forget, for each of the creators' innocents harmed (in any way) there is a debt that must/will be repaid by you/US as the perpetrators/minions of unprecedented evile will not be available after the big flash occurs.
'vote' with (what's left in) yOUR wallet. help bring an end to unprecedented evile's manifestation through yOUR owned felonious corepirate nazi life0cidal glowbull warmongering execrable.
some of US should consider ourselves very fortunate to be among those scheduled to survive after the big flash/implementation of the creators' wwwildly popular planet/population rescue initiative/mandate.
it's right in the manual, 'world without end', etc....
as we all ?know?, change is inevitable, & denying/ignoring gravity, logic, morality, etc..., is only possible, on a temporary basis.
concern about the course of events that will occur should the corepirate nazi life0cidal execrable fail to be intervened upon is in order.
'do not be dismayed' (also from the manual). however, it's ok/recommended, to not attempt to live under/accept, fauxking nazi felon greed/fear/ego based pr ?firm? scriptdead mindphuking hypenosys.
consult with/trust in yOUR creators. providing more than enough of everything for everyone (without any distracting/spiritdead personal gain motives), whilst badtolling unprecedented evile, using an unlimited supply of newclear power, since/until forever. see you there?
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
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."
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 know this is a little off topic, so it's fair to mod me down. But anyway...
Is it hard to setup any play with virtualization? For instance, I use Ubuntu Dapper Drake, and if it doesn't take very long I'd love to give one of the Edgy Eft snapshots a try. I just don't want to hose my existing setup. Does it take much time for a newbie like me to get virtualization working to the point where I can try something like that?
Maybe they should do business with MycroS0ft instead !
VMWare wants a closed source interface, Xen wants an open source interface--what's to discuss, really? I'd love to see them hash it out on the LKML as proposed (and watch VMWare get flamed)... :)
pb Reply or e-mail; don't vaguely moderate.
I'm not surprised at all that two competing companies refuse to agree on a standard.
If one can pull ahead in terms of marketshare and dominate the field, he can then control the technologies used and profit.
It would probably be best for the linux integration team to wait a couple of years before integrating in any virtualization technology just to see which solution is the better one in terms of usability and marketshare. Then they can choose whether to support the leader or undermine him.
Cheers,
Ben
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.
Don't throw stones here Oracle. Where is "FreeTNS"? Guess that's why I keep other database software using "FreeTDS".
they work great, simple, easy and fast - and best of all - they come with support and are free
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
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
departures oF want th$em there. a relatively
With Intel Vanderbuilt and AMD Pacifica I thought this was a non-issue? Guest OSs don't know they're running under a hypervisor with Xen on those platforms.
And VMWare works the same way (but does it with Ring-0 callouts, like QEMU).
What standards are they arguing about? Disk image formats? APIs for accessing dedicated hardware on the host machine? I'm guessing the latter, since that's all that Oracle would care about.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
liitle-known Mechanics. So I'm
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.
A) Cheaper upgrades to new features/releases.
B) 24/7 access to knowledgeable people about some of the more obscure capabilities or limits. Try this one, in ESX 2.5.2 there is a limit of 32 virtual NIC to map to physical NIC on the host, i.e. if you have 2 physical NIC, all your running guest servers are allowed a combined total of 64 virtual NICs, when you exceed that number you get a less than informative error message when you attempt to start the guest that needed the 65th virtual NIC. It took a call to support and working with the (IBM) technician to dig through some of the config files and documentation to identify the issue. The software was "perfect" and WAD (working as designed), the limit was even documented! Having over 6 months of smooth sailing resulted in less than perfect recall of such piddling details.
C) Also consider that in many cases the support contract is cheaper than losing a critical person for days to formal training.
VMware is pretty savvy in recognising that the real, ongoing, dollars are in good service and support. All in all my employer and I, personally, are very happy with VMware from a business and business ethics standpoint. I will keep a finger in the pot for Xen and MS virtual offerings with my personel setups at home because I like to keep abreast of the options, but in my employers production we pay for and use ESX software/support and will be deploying a number of VMware VMserver installations and customer sites where ESX is overkill.
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
Linux has a history of two separate options that do basically the same thing. There is no 'one' Linux company, nor is there a single user interface, or what about the VM in 2.4? Does it actually matter that Oracle is loosing its patience? And why should Oracle really care anyway? They are an application provider, yes I know it's a database ... big deal. The whole idea of virtualization is that the application doesn't need to care whether it is running on real hardware or virtual hardware. I don't see Oracle working with Microsoft or MySQL AB to develop a single SQL interface.
Out of curiosity, what OSes / applications were running to where you needed > 64 virtualized NICs on that host?
vi ~/.emacs # I'm probably going to Hell for this.
Actually it was just 32, I used the 64 to establish that it was a per NIC issue rather a host limit. Just needed to order additional NIC cards, easy solution just a tricky bit of diagnosis. We were outsourcing for a customer on 8 processor 48GB host server and quite a few production VM MS Windows 2003 guests including multiple load balanced terminal servers each using 2 NIC each. We had additional lab guests supporting the devlopment effort to use MIIS to synchronise user accounts and their home directories, etc between Novell ED and MS AD environments, so now you have test servers for both Novell ED, MS AD, Groupwise, Exchange and desktops on top of the production guests, eats up limited resources pretty quick.
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
We know that GNU's Not Unix, and Gnu Hasn't Been Unix for Over 20 Years (GHNBUFO20Y), though of course Unix these days mostly _is_ the community effort, regardless of whose compiler or kernel is used. For instance, I tend to use X-Windows/Linux most of the time, and vi instead of emacs, though fairly often inside a Bourne-clone shell on Xterm, which makes it BSD/GNU/X/X/Linux, unless you want to contend that using GCC to compile the vi source makes it BSD/GNU/GNU/X+GNU/X+GNU/Linux+GNU. If I liked csh, that'd be BSD/BSD/X/X/Linux. I'd really prefer ksh to bash, but which would make it BSD/UNIX/X/X/Linux, or pedantically BSD+GNU/UNIX+GNU/X+GNU/X+GNU/Linux+GNU if you insist on the compiler taking credit. Then of course there's the problems of kernels being built with different GCCs than application layers, which probably makes it BSD+GNU'/GNU'/X+GNU'/Linux+GNU.
Now, why was it that the Virtualization people are getting into arguments about different layers again?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Well, I knew I was going to take flak for saying that. :)
I'm aware of the difference between the GNU toolset/userland and the kernel. However, the GNU utilities are, collectively, a clone of a sort of generic UNIX userspace. That's the joke behind the name "GNU's Not UNIX," because just by looking at it, it looks a whole lot like UNIX. (This is freely admitted by the FSF: "We decided to make the operating system compatible with Unix because the overall design was already proven and portable, and because compatibility makes it easy for Unix users to switch from Unix to GNU.")
We can argue as to whether or not Linux (the kernel) was a clone of a Unix kernel or not; I suppose it's probably a stretch to call it a 'clone,' but it's definitely reinventive, if a few generations removed from any actual Unix. Torvalds had studied Minix, and Minix is certainly "Unix-like," at least on the surface. That none of them (Linux, Minix, UNIX) shared any code (initially--they may now) underscores my point about the re-inventiveness of each effort.
Note that I'm not alleging any sort of plagarism or intellectual dishonesty here; on the contrary I was trying to use Linux as an example of how sometimes reinvention can be a good thing. I'm quite sure (because I heard it first-hand) that a lot of UNIX users thought that GNU/Linux was unnecessary and redundant when it first was developed, but in retrospect they were wrong. That's the point I was getting at: sometimes it can seem like people are reinventing the wheel, but in doing so may be doing something rather terribly important. (Although it may not be evident until later.)
That said, they might just be reinventing the wheel. It's tough to say until later, which is why I said projects that seem to do the same thing ought to be carefully considered before a lot of duplicate effort is expended.
On the whole Linux/GNU/"GNU-Linux" thing: I think it's pretty well accepted by now that "Linux" is not just the name of a kernel, but the name of an entire family of operating systems, which have in common a particular kernel. I certainly don't mean any disrespect to RMS and the rest of the GNU people, but GNU/Linux doesn't exactly roll off either the tongue or the keyboard. The only time I write out "GNU/Linux" is when I think there's a chance that the whole OS and the kernel by itself are going to be confused, or where the userspace and kernel are being discussed independently. (Actually I think it's most common today to use "Linux" to refer to the OS or OS family collectively, GNU to refer to the toolset, and "Linux kernel" to refer to the kernel.) In my original post I was referring to Linux collectively, both the GNU userland and Torvalds' kernel, as a Unix-like OS (which it is, or at least was; in many ways it's surpassed Unix now) which is reinventive in nature. But you're right, I should have been more clear.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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)
Everytime I see a post about Xen, I cringe.
Technology is good. Open Source is good. Management is AWFULL.
As we all know, it is HOW a business is run that makes can make a product mediocre or bad. I have interracted with with some of the clowns who suffer from chronic managerial bad judgement.
Here are the problems with Xensource, from the inside:
1) Penny wise & pound foolish.
They are burning up their VC (not on paying many good engineers good sallaries, but) on: renting a furnished appartment in prime real estate, in downtown San Fransisco for somethinng like $5,000 PER MONTH. Why? So the creator of Xen can have a nice cushy place to crash for the 1 week per year that he visits the company from accross the pond. They are kissing his monkey.
2) Too many VPs, hiring their friends...from their fundamentalist church, their family tree & from the department of arrogance.
3) Hired incapable tech support.
The lady they hired for tech support was incapable of understanding troubles with Xen. Then gets fired because she couldn't perform. Xen managers can't hire good people.
4) Clueless CEO. Frequently gets: new gadgets purchased for him & a frequently kissed hinney.
Their VC sponsor (Seven Rosen Funds) can't manage their own office... let alone install an effective CEO.
5) Using Xen on production computers. Don't bother E-Mailing them about a trouble with virtualizing Exchange (on Windows). They won't get it. They run their E-Mail server on Exchange, which is virtualized. How are you supposed to fix a bug with your software when your compiler has been virtualized & has bugs? Can you say catch-22?
6) They are good on image & bad on results.
7) Their I.T. guy is overworked & pussy-whiped by a bible-thumper boss, to work overtime without pay. Isn't that illegal?
Xen and VMWare do not do the same thing at all. VMWare is like Qemu, it's a machine emulator; it uses a dirty hack in kernel space to avoid emulating a large set of the code being run by having a fake environment set up for it and running it directly in that, on the CPU. Xen is a paravirtualizing hypervisor, it supplies services to an operating system and expects the operating system to use them to interact with it; the OS is actually a Ring-3 userspace program (think UserMode Linux, except this approach allows actually attacking the problem directly rather than trying to squeeze it into an existing set of restrictions; we now have upper level OS APIs to assist the user mode operating system). Trying to say they should "use the same interface" is asinine; it's like saying IRC and Microsoft Word should use the same protocol.
Support my political activism on Patreon.
No surprises here... people arguing over API's and the kernel. Gee, read kernel-traffic lately?
+++OK ATH