Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×

Oracle 'Losing Patience' with XenSource, VMware 165

Posted by Zonk from the just-hug-and-make-up dept.
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."
This discussion has been archived. No new comments can be posted.

Oracle 'Losing Patience' with XenSource, VMware More

Oracle 'Losing Patience' with XenSource, VMware

Comments Filter:

  • Compromise (Score:4, Insightful)

    by neonprimetime ( 528653 ) on Tuesday August 01, 2006 @08:41AM (#15824480)
    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.

    • Re:Compromise (Score:5, Insightful)

      by Anonymous Coward on Tuesday August 01, 2006 @08:50AM (#15824510)
      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?

      • Long history of wheel reinvention (Score:5, Insightful)

        by Kadin2048 ( 468275 ) <slashdot.kadin@xoxy . n et> on Tuesday August 01, 2006 @09:34AM (#15824759) Homepage Journal
        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

          • What rubbish.

            GNU/Linux is a clone of Unix.

          • 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

      • Re:Compromise (Score:4, Informative)

        by morgan_greywolf ( 835522 ) on Tuesday August 01, 2006 @09:57AM (#15824888) Homepage Journal
        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 give
        2 - Make your racks easier to manage and recover (adding failover and high availability)
        3 - Ma

    • Re:Compromise (Score:5, Funny)

      by Ant P. ( 974313 ) on Tuesday August 01, 2006 @09:19AM (#15824660)
      As long as they both write their code using vim, I don't care which one I use.

    • Are you kidding? (Score:5, Funny)

      by Moraelin ( 679338 ) on Tuesday August 01, 2006 @10:35AM (#15825155) Journal
      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!!!"

  • Of course.... (Score:3, Insightful)

    by Whiney Mac Fanboy ( 963289 ) * <whineymacfanboy@gmail.com> on Tuesday August 01, 2006 @08:41AM (#15824486) Homepage Journal
    Oracle's interoperability with competing products is perfect. Yeesh.

    • Re:Of course.... (Score:3, Insightful)

      by smallpaul ( 65919 )
      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.

          Right, what wo

  • Impatience is a Virtue (Score:4, Insightful)

    by Doc Ruby ( 173196 ) on Tuesday August 01, 2006 @09:03AM (#15824580) Homepage Journal
    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...
    • Yep, like ODBC you mean?
    • Moderation +2
          70% Insightful
          20% Overrated
          10% Flamebait

      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.

  • fleshing out the question (Score:5, Interesting)

    by rodentia ( 102779 ) on Tuesday August 01, 2006 @09:15AM (#15824635)
    The Reg is leading with a story putting meat [theregister.co.uk] 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?

  • I read 'offline meditation'. But then, maybe that's exactly what they need.

  • Typical. (Score:2, Interesting)

    by pb ( 1020 )
    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)... :)

    • Re:Typical. (Score:4, Informative)

      by InsaneGeek ( 175763 ) <slashdot@@@insanegeeks...com> on Tuesday August 01, 2006 @09:51AM (#15824845) Homepage
      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.
      • Ah yes the essence of Free software. Try and force people to use it and call it Freedom.
        • No one is forcing anyone to use anything.

          Do you think that Linus should be forced to accept the VMI patches into his kernel?
      • 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

  • Ego (Score:2, Interesting)

    by Anonymous Coward
    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.

    • Re:Ego (Score:3, Interesting)

      by jellomizer ( 103300 ) *
      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.

  • Part of the problem: Xen isn't baked yet (Score:4, Interesting)

    by postbigbang ( 761081 ) on Tuesday August 01, 2006 @09:34AM (#15824763)
    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.

  • VMMs (Score:4, Insightful)

    by thermostat42 ( 112272 ) on Tuesday August 01, 2006 @09:42AM (#15824799) Homepage
    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?

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

  • Personal opinions (Score:5, Interesting)

    by kscguru ( 551278 ) on Tuesday August 01, 2006 @10:49AM (#15825256)
    Disclaimer: VMware employee, personal opinion.

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

    • Re:Personal opinions (Score:2, Interesting)

      by Anonymous Coward
      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.

    • Re:Personal opinions (Score:5, Informative)

      by Anthony Liguori ( 820979 ) on Tuesday August 01, 2006 @12:01PM (#15825800) Homepage
      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

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

        Disclaimer: Just a virtualization user (currently VMware, Linux host with Windows guests), offering some feedback and requesting some enlightenment.

        The problem with VMI is that it hides the hypervisor interface from the guest.

        By "guest" here, do you mean the particular hypervisor instance (e.g. VMware or Xen) or the guest OS? If it's the OS, I very much want it oblivious to the fact that there's vi

        • 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

      • Re:Personal opinions (Score:4, Interesting)

        by kscguru ( 551278 ) on Tuesday August 01, 2006 @11:09PM (#15829470)
        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.)

  • 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
  • No surprises here... people arguing over API's and the kernel. Gee, read kernel-traffic lately?

Slashdot Top Deals

1000 pains = 1 Megahertz

Close