Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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

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. Perhaps different performance characteristics or access to system devices might be an issue. It takes serious planning and commitment not to change the api. The linux changelog suggests this is a big problem for some. The argument that its better doesn't always cut it.. why do you think windows is bloated?

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.

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.

I'm sure you've been corrected on this point already, but if not, I'll reinforce it.

Linux the kernel was probably a pseudo-clone of the minix kernel, but the surrounding operating system (often called "Linux"), was most-certainly not a reinvention of anything that existe

The original poster was saying that "Look, they're just a couple of computer software companies, they ought to be able to get along with each other." Your post is an example of why this might not be true:-)

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

Perhaps you should do a little research instead of posting the same drivel that I posted when I was in high school.

The phrase "TCP/IP" isn't primarily about credit, and neither is "GNU/Linux", despite what rms may claim. The phrase "GNU/Linux" is about disambiguation. Unlike with, for example, FreeBSD, Linux does not have a single userland, so we need to be specific. GNU runs on top of all sorts of kernels, and there are several userland environments that can be constructed on top of Linux kernel. GNU

Oh, nonsense, of course it's about credit. Referring to Debian or Mandrake is disambiguation, but referring to GNU/Linux is purely a credit ploy. It's an expanded version of credit - it's bragging about the whole Free-As-In-Speech-Not-Beer Software movement, and not just abour RMS, but it's definitely about credit.

As far as research goes, do you even have your Mentally Contaminated button? I've worked on far more non-Linux variants on Unix than I have on Linuxes - I started with v6 using Mashey Shell,

Oh, nonsense, of course it's about credit. Referring to Debian or Mandrake is disambiguation, but referring to GNU/Linux is purely a credit ploy. It's an expanded version of credit - it's bragging about the whole Free-As-In-Speech-Not-Beer Software movement, and not just abour RMS, but it's definitely about credit.

I'm well aware that the GNU project's push for "GNU/Linux" is about credit. My point (which I probably overstated) is that it is nevertheless valid to use "GNU/Linux" for disambiguation in cert

OK, occasionally there are cases where you not only care that the utilities are GNU-flavored and the underlying OS is Linux as opposed to BSD or something, but you don't care which Linux, so probably only 99.99% of the uses of "GNU/Linux" are spurious and 0.01% are legitimate:-)

But generally anybody who rants about how you SHOULD use the term isn't saying anything meaningful and can be ignored.

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 [gnu.org] by the FSF: "We decided to make the operating system compatible with Unix because the overall design was already proven and portable, and because com

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.

VMWare and Xen are just tools that are made available for people with curiosity or need to re-invent their own wheels (with some skill and patience). Xen is just that, a set of tools - just like VMWare, its not meant to be any kind of stand alone solution. You use Xen (or VMWare) in conjunction with a well thought out plan to help you:

1 - Come closer to squeezing out every drop of resources your racks have to give2 - Make your racks easier to manage and recover (adding failover and high availability)3 - Ma

Seriously people, this is computer software we're talking about, not Israel and Hezbollah.

You're kidding, right? This is computer software, the battleground of OCPD [wikipedia.org] 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!!!"

This issue has nothing to do with interoperability. It is about getting changes into the Linux kernel. I don't see it as particularly (5, Insightful) to say: "Oracle isn't perfect therefore they shouldn't complain about other companies." Oracle is an influential company trying to solve a logjam slowing important technology adoption in Linux. Good for them!

This issue has nothing to do with interoperability. It is about getting changes into the Linux kernel.

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:

VMware is fast losing its patience with both Oracle and Postgresql over their reluctance to work together to help develop a single interface that will integrate a variety of clustering filesystem solutions in the Linu

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?

Right: nobody is trying to get Xen and VMware to work with each other. Substitutability might be a better term.

VMware is fast losing its patience with both Oracle and Postgresql over their reluctance to work together to help develop a single interface that will integrate a variety of clustering filesystem solutions in the Linux kernel.

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

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.

Yes, there are SQL language standards (which are lamentably followed by commercial and open source databases at about a 7-year lag). But there are no standardized protocol interfaces for connecting to databases. So every different database requries a custom protocol driver of some sort. Even programming-language-specific but "standard" database APIs (ODBC, JDBC, ADO.NET, whatever) require a driver layer beneath them to speak the particualr database connection protocol needed.

Although SQL is defined by both ANSI and ISO, there are many extensions to and variations on the version of the language defined by these standards bodies. Many of these extensions are of a proprietary nature, such as Oracle Corporation's PL/SQL or Sybase, IBM's SQL PL (SQL Procedural Language) and Microsoft's Transact-SQL. It is also somewhat common for commercial implementations to omit support for basic features of the standard, such

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.

There's major differences between a hypervisor based virtualization system and a fatter emulation method. Such differences tend to express themselves in all sorts of odd places, where you might otherwise expect a unifying API.So why is Oracle crying about it? Instead of complaining that other companies need to get their act together and bind two different solutions to a problem in a way that serves Oracle, Oracle could write one management interface that does what they want for each of the two environment

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.

Ego is Open Sources Greatest gift and it biggest fault. The reason a lot of people write Open Source Applications is so their name is on it and they get the warm and fuzzies that they are part of a larger application, or a widely used application. But it also causes people work hard to make sure their contribution is the most important and they will fight to the teath either right or wrong to get their contribution in.While closed source or people working in comerical their EGO is more professionally cont

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.

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.

Wtf is up with all the food analogies? It's probably the hash brownies affecting the discussion - Xen isn't baked yet, but I am...

Seriously, though, VMWare works well enough to support lots of production environments, and Xen doesn't, and therefore Xen loses unless you're doing one of the things it supports reliably. And Xen only supports open-source clients that you've Xena-fied, or owner-modified closed-source clients, while VMWare apparently supports almost anything. If you want to run Windows as a

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?

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.

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.

Performance in full virtualized mode is noticeably worse than in paravirtual mode, so people are fighting over paravirtual interface standards.

For now, this is true. The expectation is that over time, using hardware virtualization will be beneficial. The paravirt_ops interface is designed so that there's at least one op corresponding to every trappable instruction. In the future, we'll be able to rewrite the calling location of a paravirt_op. One of the reasons for this is so that we can make the decisi

One that was set on HARDWARE instead, a virtualization support at processor level?

No, that's not what this discussion is about. This is about a *higher* level interface than that provided by hardware. This whole debate is really about an API of less than 10 functions that do higher level operations. By hooking this higher level operations into the hypervisor, you can dramatically improve performance.

A canonical example is updating page tables. Normally, if you were to hook at the hardware level, updatin

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

Why do I want Xen and VMware to compete, and why would I want Oracle to "know" it was running in a vm? My preference would be for the application not to know if it was running in a VM or on bare metal.

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.

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.

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 [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

See, this is why I still read Slashdot. Informed opinions from interesting people! Thanks for stopping by to chat.

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

Fair - and in hindsight, I should have noted that distinction, apologies. (That particular MS/XenSource alliance happens to be at the top of my stupid list... it hurts Xen, XenSource, all other virtualization businesses (via FUD), and ultimately helps only Microsoft).

I actually don't like VMI either. I still believe the hypervisor should be hidden - if the OS wants a virtualized timer, it should use a paravirtualized device driver, the API for which is independent of the hypervisor's core interface - but I don't think that loading a ROM is the way to load an interface. It's re-inventing BIOS. Frankly, I don't think there is a good solution. And once the CPU vendors get their acts together and actually virtualize the MMU (yup, they virtualized the CPU but not the onboard MMU, VT/Pacifica v1 is as weak as a 286) then the pressure on paravirtualization decreases as the performance advantage disappears. (Device paravirtualization is still needed - but that's easy! And the ground is ripe for competition in the feature set of an emulated device.)

Hah! I knew it. Xen's just not going for the VMI approach because it's pretty much what L4 guys have supported for quite some time. You couldn't help but do some "friendly" bashing, could you.;-) (Oh well, neither could I.)

No, L4 hasn't supported it for a long time--only just recently. I said they don't count because they're doing it with previrtualization which is exceedingly cooler than any of this other stuff.

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

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 a

Oracle is a significant player in the open-source community and, as both an open-source and commercial database provider, has a very strong interest in getting virtualization technology into the kernel.

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.

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 sho

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 don't think that is the position of the granparent. I believe it is more on the line of "If you aren't open, then don't pretend to be open. Opening up the minimum of resources, just to appear in the headlines is not fooling anyone".

I don't like this atitude of labeling stuff as evil and good. This tends to misrepresent almost everithing, google is good, sure what about all those secrets and the censorship in china (I actualy don't think that this is google's fault but many people think it is). MS is evil to root, but many people use their software and like it (it's not for me, but who am I to say what's best for everyone?). And so it goes, up to the infamous Bush's "axis of evil" that aparently if you classify to this group then it's okay if you are arrested and sent to Cuba to be tortured.

Come on people there are shades of gray, and even shades of yellow, green, blue and other colors. There are many sides, many ways to see the same fact, and many time what seems pure black from one of those sides can be clear as whater in other point of view.

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.In addition to the topic links here's another.

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.

That doesn't make any sense. Since Xen is open source it's not like the interface could be usefully patented or anything, so there's nothing stopping any other hypervisor from just adopting Xen's design!

That's like saying because it's opensource ReiserFS has to code using the exact same kernel hooks specific ext3 as they are all opensource and do the same thing (filesystem). Or that all network protocols can only talk using the telnet protocol as it's opensource, not patented, everyone must be forced into using just that, no direct use of http, ssh, SIP, etc everything must now be tunneled in the existing telnet process. With both those examples technically it could be done, you could try and force resie

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

But it's a virtual abstraction that others cannot use, only Xen can use it. You'd rather make a concious decision to choose the Xensource commercial product method be the only way and then force everyone else to make constant shoe-horn changes in the kernel? What kind of stuff are you on here? It's like saying that instead of using http we should have *extended* telnet protocol to be able to not break telnet but support http, it's truely that stupid. If you want a non-stable, constantly changing kernel

Tell me, dipshit, at what point did I ever imply that VMWare should be "forced" into using the same interface?

Unless I'm mistaken, the issue here is that VMWare and Xen have different interfaces, and both want theirs to be the "official" one. So, no matter what, at least one of them will have to change or else the entire premise is moot. In other words, you said the problem was "Xen source was pushing a design that was exclusive to Xen," but the problem (as I understand) is that VMWare was pushing a design

Unless I'm mistaken, the issue here is that VMWare and Xen have different interfaces, and both want theirs to be the "official" one.

"For a long time, it was thought that we'd just merge the Xen patches as-is and be happy. But then, Linux would only run on Xen," Morton said. Instead, VMware programmers suggested a documented, stable interface between the kernel and the hypervisor -- and they're preparing one, he said.
"From a high-level design perspective, I think that VMware's point is a good one, and

It sounds that way, at first. But if you read closely, you'll notice this:

VMware programmers suggested a documented, stable interface between the kernel and the hypervisor -- and they're preparing one, he said. [emphasis mine]

To me, that seems to imply that VMWare isn't actually trying to make a collaborative standard, but rather a proprietary, albeit stable and documented, interface that's custom-tailored to their favored design.

In other words, neither side seems to want to make compromises, although VM

After finding out exactly what VMWare's proposal was, I don't blame them! VMWare, as I suspected, was trying to give themselves an unfair advantage by making the standard a binary blob! From the article:

The essential difference between the two is that the Virtual Machine Interface proposal from VMware basically allowed it to hook the hypervisor into the kernel at load time, without ever needing to expose the hypercall API itself, or any of their closed source code.

Let's look at your post, do you mention an open standard API? nope. Do you mention using Xen's? yes, multiple times infact. What is the issue? Xen has requested Xen specific patches to the kernel, VMware has requested generalized patches to the kernel. If you accept Xen specific kernel patches it kind of makes a generalized interface redundant doesn't it? Why would you ever have a specific Xen interface in the kernel and than a generalized one for everyone else? Do you realize how stupid that would b

You understand wrong on the VMware exclusive statement, VMware is not pushing their exclusive one, they are saying that they need a generalized one that can be used by anyone (I'm not sure how you can get more opposite of what you are saying).

What I'm saying is that since VMWare is apparently working on it by themselves without Xen's input. What that means is that they're likely writing it to work perfectly with the way their software works, while Xen (and anyone else) would have to change the way their so

Simon Crosby, the CTO for XenSource, said:"The VMware team should be praised for engaging an open dialog with the Linux kernel and Xen communities, and they are actively engaging in the process," he said.

But that doesn't change the fact that VMWare's actual proposal isn't acceptable. Now that I read the article and see what the problem actually is, it's obvious that Xen is right and VMWare is wrong. In fact, my guess that VMWare was trying to give themselves an unfair advantage was spot-on -- they're trying to do put in proprietary code! VMWare's proposal "left the community having to design open-source code to interface to a "binary blob" of a closed source hypervisor."

What isn't acceptable? What proprietary code? Are you truely that stupid? Read it again and quote me where it forces the linux kernel to accept proprietary code in the mainline kernel (against the GPL). What it does allow is a standardized way for proprietary & non-proprietary code to be able to talk to the kernel if you want to. Proprietary code in the mainline kerenl... you really aren't that moronic are you? You are intelligent enough to understand the difference?

According to what I've read, it would work a lot like nVidia and ATi's proprietary graphics drivers, except that it would be worse because it would mandate a standard ABI. It's not okay for graphics drivers, and it shouldn't be okay for virtualization either!

Maybe you should do some more reading, especially since your last post basically admitted that you hadn't been reading anything previously and were speculating.Here's a thought, first start with the actual VMI interface: http://www.vmware.com/interfaces/vmi_specs.html [vmware.com]

Read that, and see that it's a standardized API

Then read this again (actually for the first time) that I posted earlier

You know, in addition to reading that eWeek article you posted, I also read the paper presented at the 2006 Linux Symposium [linuxsymposium.org], which the eWeek article referenced. I know how the thing works now!

Nevertheless, I'll read the articles you linked, and use them to refute your points. From your first link:

To reduce the maintenance burden as much as possible, while still allowing the implementation to accommodate changes, the design provides a stable ABI with semantic invariants.

I think you are missing the point of what that ABI is there for, that ABI is so that you don't have to recompile the kernel everytime to match things up. Instead of everytime I virtualize something I had to recompile the kernel for the virtual machine, I have a standardized ABI for older and newer kernels to be able to talk to the hypervisor. What VMware proposed an open API framework that anyone could use, which would allow different kernel revs to use a stable ABI to talk to, rather than recompile to the

I think you are missing the point of what that ABI is there for, that ABI is so that you don't have to recompile the kernel everytime to match things up.

I know damn well what it's for! But the problem is that it has the side effect of introducting unauditable, unsupportable, un-Free binary blobs into the kernel. If we're going to do that we might as well close the whole source and call it Windows! It goes against everything Free Software stands for, and it ought to be a GPL violation (and if it isn't, it's

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.

I suggest you look at the announcement of Xensource & Microsoft and compare that to when the generalized vs Xen specific hypervisor in the kernel issue began, and check and see if the timeline fits. Hint: Xensource announced partnership with Microsoft July 18th, my link above was from April 13th.

But if one looks at the post he put a cause of the problem being Xensource & Microsoft teaming together, when the problem existed *prior* to it. If the problem existed prior, it cannot be the causation, it can be additional factors but it cannot be the causation. If it was only about Xensource & MS getting together than it would have been resolved prior to the announcement, because there was no Xensource & MS. There must be other problems that have been going on longer than that cooperative a

VMWare has a business to protect, but that business is -- for the most part -- not selling software. It's providing services and support. All virtualization servers short of VMWare's ESX are now free. Consequently, it is in VMWare best interest to produce perfect software. Perfect software requires very few support staff, meaning all those support and services fees are almost pure profit and no overhead.

Consequently, it is in VMWare best interest to produce perfect software. Perfect software requires very few support staff, meaning all those support and services fees are almost pure profit and no overhead.

Not necessarily. If VMWare writes perfect code and gives it away for free, then eventually customers will catch on, and will refuse to get support contracts. After all, if you are reasonably confident that the software you just downloaded is perfect, why on earth would you go through the unecessary trou

Xensource [xensource.com] is a business just like vmware. A part of their product portofolio is opensource, but their cooperation with MS shows they are not afraid of closed source. And just because it is open source it is not by definion good, because you will still need their support to active keep developing xen as new OS and hardware that needs to be virtilized keeps ermerging.

They both offer free (as in beer)and paid/supported products so i cannot see vmware or xensource is more evil than an other. I have no clue what

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.

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.

Today, I'm installing a Win2K in a VMWare virtual machine using their free VMWare Server (www.vmware.com), and I must say it's far more slick and the performance is fantastic. If you got as far as installing Ubuntu, you can install VMWare and run Ubuntu in it. It's cake (and tasty cake too, I might add).