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."

Wrong.

[Yonder Way]

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. [xensource.com]"

Re:Typical.

[InsaneGeek]

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.

Re:Compromise

[morgan_greywolf]

Not necessarily. Linux seems to be about new ideas and reinventing the wheel. Why are there so many file systems for example? There are valid reasons to have different interfaces.

Indeed. Why are there so many filesystems? Because there are good reasons for it. Some filesystems, like ISO9660, provide access to standards-based media (CDs, DVDs), others like ext3 are intended to provide advanced features like journalling and still retain backward compatibility with ext2 utilities. Still others, like ReiserFS and XFS are intended to provide the most advanced features and highest performance possible; ReiserFS as an overall enterprise-class server filesystem and XFS provides excellent performance for streaming media applications. JFS tries to add compatibility with AIX5L. Each filesystem addresses a different need.

This is also true of Xen vs. VMWare. VMWare was originally geared at doing desktop stuff; they later tuned things for server virtualization; but the aim has always been to provide as much compatibility with all the major guest and host operating systems. Xen is aimed at doing server virtualization with maximum performance -- the number and types of guest OSes isn't as important, as Xen basically only supports running Linux on Linux. Other OSes may work as well, but the main goals are different.

Re:OT: Is it hard to start using virtualization?

[spun]

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.

No, it's pretty easy.

[Kadin2048]

No, it does not.

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 /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.

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.

Re:There isn't already a "default" interface?...

[spun]

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.

Re:Personal opinions

[Anthony Liguori]

Disclaimer: VMware employee, personal opinion.

Disclaimer: Xen hacker, personal opinion :-) Didn't think it was necessary to mention but what the heck :-)

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 :-) 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.

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 ;-)), VMI would already be in the kernel.

(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

Inside information on XenSource

[Anonymous Coward]

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?