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

Comments

Compromise

[neonprimetime]

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

[Anonymous Coward]

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?

Re:Compromise

[Lissajous]

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.

You think? What we have here is two companies that are effectively competing to make theirs the best-case solution to the problem. It gets adopted, maintenance/support contracts come their way. They're not in it for the kudos, they're in it for the money.

Re:Compromise

[Ant P.]

As long as they both write their code using vim, I don't care which one I use.

Re:Compromise

[neonprimetime]

vim is just too pretty for me, i prefer nano

Re:Compromise

[Anonymous Coward]

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

Or use PHP and get both...

Re:Compromise

[Poltras]

More precisely, to increase their investissor's stock value. Not necessarly by making money, but flirting with Xen is probably not in their interest or goals right now. Too bad.

Re:Compromise

[Millenniumman]

Nano? That bloated editor? ed is best.

Re:Compromise

[neonprimetime]

oops, did i say nano? i meant nano-tiny

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:Compromise

[Anonymous Coward]

"Why are there so many filesystems?"

I am not an uber-geek so maybe I am wrong here but as far as I can tell no one filesystem could ever be perfect for all situations. Some are excellent for many small files, some are better for larger files, some for specific types of access for say a data warehouse.

I do not really think you can say they are reinventing the wheel. What they are doing is taking these individual algorithms for their individual problem space and improving them.

Re:Compromise

[Anonymous Coward]

It's worth nothing that Xen's deal with Microsoft basically forces their hand... they can't compromise. So much for being Free software.

Re:Compromise

[tinkertim]

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 - Maximize your R&D dollars whenever possible.

Why ask the tool companies to build the buildings ... isn't that the job of the builders?

I think most /. readers at least once in their life played with Leggo building blocks, yes? Well, did anyone actually build the toy that was pictured on the front of the box? or did you just chuck all your cool new pieces in the box with the rest of your blocks and use everything at your disposal?

Oracle is way off and is asking Xen and VMWare to shift focus and bastardize their producs, which is only going to serve to make a lesser product. Let Xen keep going , read the Xen devel list - they be jammin.

Whining for the sake of whining? Oracle - stay outta my toolbox please :)

Of course....

[Whiney Mac Fanboy]

Oracle's interoperability with competing products is perfect. Yeesh.

Re:Of course....

[smallpaul]

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!

Re:Of course....

[Whiney Mac Fanboy]

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

Oracle is not the sort of company that cooporates well with others with regards to common APIs, etc. Why the hell should we take advice from them about this seriously?

Re:Of course....

[smallpaul]

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 would be wrong with an article like that? Why shouldn't companies criticize each other when intransigence causes consumers difficulty.

Why the hell should we take advice from them about this seriously?

They aren't offering advice. They are stating their opinion that this problem is costing them revenues and delaying customer implementations of virtualization. Do you agree with them or do you think that there is no problem with the fact that Xen is (apparently) trying to push a Xen-specific interface into the Linux kernel and lock out rivals? If you agree with them, then does it matter whether the messenger is Oracle, Microsoft or Satan himself? And if you disagree, then why don't you state your reasons rather than using an ad hominem approach? Nobody claims that Oracle is doing this out of the goodness of their heart. That's a non-sequiter.

It's also incorrect to say that Oracle does not support standards. Oracle supports standards when it is in their own best interest, which may be because of pressure from other companies or customers (or customers advised by other companies to press Oracle on standards compliance). It is precisely because Oracle understands how these decisions are made (on the basis of cash and pressure) that they are making this statement. Good for them!

Impatience is a Virtue

[Doc Ruby]

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

Re:Impatience is a Virtue

[Silverstrike]

http://en.wikipedia.org/wiki/SQL#Standardization

There are standards. And there has been for a very long time.

Re:Impatience is a Virtue

[Aeomer]

That's the 'standard' but there are a million and one extensions that actually make SQL usable in a modern context. Standard SQL just does not cut it any more. The problem is the extension between mySQL, Oracle, MSSQL etc are NOT interchangable. If you find you can do everything you need with just standard SQL they I don't think you are running any really big (multi-terabyte) systems.

Re:Impatience is a Virtue

[oPless]

Yep, like ODBC you mean?

Re:Impatience is a Virtue

[Thundersnatch]

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.

I recall reading about a Microsoft-built web-service (SOAP) based database access protocol, but I'm not sure if anything ever came of that, or if it was ever submitted to a standards body of any type.

Re:Impatience is a Virtue

[Anonymous Coward]

There are standards. And there has been for a very long time.

The problem is that they are not enough and not implemented well enough, making non-trivial SQL non-portable.

Re:Impatience is a Virtue

[jellomizer]

I don't think you are running any really big (multi-terabyte) systems.

Or the database is layed out and indexed correctly and you can get all the data you need, using basic SQL and you only need to pull a couple records at a time.

Re:Impatience is a Virtue

[Doc Ruby]

The nice thing about standards is that there are so many to choose from:

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 as the DATE or TIME data types, preferring some variant of their own. As a result, in contrast to ANSI C or ANSI Fortran, which can usually be ported from platform to platform without major structural changes, SQL code can rarely be ported between database systems without major modifications. There are several reasons for this lack of portability between database systems:

        * the complexity and size of the SQL standard means that most databases do not implement the entire standard.
        * the standard does not specify database behavior in several important areas (e.g. indexes), leaving it up to implementations of the standard to decide how to behave.
        * the SQL standard precisely specifies the syntax that a conforming database system must implement. However, the standard's specification of the semantics of language constructs is less well-defined, leading to areas of ambiguity.
        * many database vendors have large existing customer bases; where the SQL standard conflicts with the prior behavior of the vendor's database, the vendor may be unwilling to break backward compatibility.
        * some believe the lack of compatibility between database systems is intentional in order to ensure vendor lock-in.

That's just the beginning of the very next section after the one you cited. A much longer section about incompatibility than the brief one you cited about the standard. That's why Oracle needs to learn about single interfaces at least as much as do Xen and VMWare.

Re:Impatience is a Virtue

[Doc Ruby]

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.

Re:Impatience is a Virtue

[Qzukk]

using basic SQL and you only need to pull a couple records at a time.

Please, tell us how to pull "a couple records at a time" using only basic SQL.

I use postgres's "SELECT .... LIMIT x OFFSET y;" everyday. I used to use mysql back when they used "LIMIT y, x", though now they're supporting LIMIT/OFFSET for "compatibility with postgres".

Oracle basically appears to be "create a cursor, move the cursor forward y rows, then read x rows". Or you can use the SELECT ROW_NUMBER() OVER (ORDER BY somefield) AS rownum ... WHERE rownum>y AND rownum<=x+y ... on recent versions. Without the OVER (ORDER BY...), Oracle would basically select x unsorted rows in the WHERE clause and sort only those x rows.

Microsoft SQL server has a SELECT TOP x ... command, but no "offset". Googling, it looks like it takes several nested queries to pull that off, and then only if you're lucky. The MSDN site declares that the "official way" is to keep track of the last result from the previous set and do a SELECT TOP x ... WHERE sortedidfield>previousresult which requires that the sorted field be UNIQUE, or else you might miss some if they didn't all fit on one page in the first place.

Re:Impatience is a Virtue

[fishbowl]

Why are you working with row numbers instead of ORDER BY and comparisons to a sortable key?

Re:Impatience is a Virtue

[Qzukk]

Why are you working with row numbers instead of ORDER BY and comparisons to a sortable key?

Why not? Lets say that I want the second page of 10 results from a query. If I told you that the query results were sorted by tablefoo.date, what query would you use to get results 10-20?

Re:Impatience is a Virtue

[An ominous Cow art]

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

Offtopic, but: I've often wished there were a way to see how my moderations fared in metamoderation.

Re:Impatience is a Virtue

[Anonymous Coward]

using basic SQL and you only need to pull a couple records at a time

there are plenty of places where "a couple records" would be considered amusing. I'm pulling, sometimes, gb sized record sets from one database currently althrough indirectly.

Re:Impatience is a Virtue

[Anonymous Coward]

I can only assume you're shooting for a "funny" mod.

Note that ODBC _still_ retains many of the incompatabilities of the various databases as soon as you try to do anything beyond the least-common-denominator of databases (i.e. Microsoft Access capabilities). Try spatial types (either the SQL Standard or the OGC standards); try the SQL Standard OLAP features; etc through ODBC and you'll be sorry. Heck, try even using the SQL Standard types or functions through ODBC and see how far you'll get.

Re:Impatience is a Virtue

[fishbowl]

"Why not? Lets say that I want the second page of 10 results from a query. If I told you that the query results were sorted by tablefoo.date, what query would you use to get results 10-20?"

I *wouldn't*.

I would insist that you either give me a date range, or index the query on some ordinal key.

I would inform you that you need some means of doing the query that supports a cursor, or else
you need to accept the consequences of your design error.

And yes, I really would tell you this, even if, especially if, you were paying my consulting rate to analyze your database problems.

Re:Impatience is a Virtue

[Anonymous Coward]

I would inform you that you need some means of doing the query that supports a cursor

Try to avoid using SQL Server cursors whenever possible. Of course, maybe using MS SQL is a design error ;) Regardless of what SQL server I would use, as your client I'm sure you'd make a pretty penny helping me optimize my connection pool to work out how many seconds I should hold cursors open before I decide that the user has surfed away from my website and won't be needing the query anymore. We might even discover that 90% of my users don't even press "next page" and that I'm establishing all these cursors for nothing, when all I really needed was the first 10 results, in whatever language it takes to get them.

Re:Impatience is a Virtue

[fishbowl]

I didn't read the article, but I will. Cursors aren't evil. I'm an Oracle developer with more than a decade of experience, mind you, but I am no DBA. I'm also not willing to comment too much on this kind of speculative, hypothetical design.

Re:Who cares.

[MilwaukeeCharlie]

If you had bothered to RTA, you'd have seen that, evidently:

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.

This may explain why I got a call recently from an Oracle rep, talking about their db solutions. I sort of laughed, since I work for a small nonprofit organization, but she assured me that they did have solutions for small and medium-sized companies. I thanked her for her time without asking for more details, but perhaps this newly acquired Berkeley product was why my company was targeted as a potential customer.

Re:What does VMWare have anything to do with this?

[Anonymous Coward]

Perfect software? Thats a joke right? Check out their bugs that seem to never close:
http://bugzilla.xensource.com/bugzilla/buglist.cgi ?query_format=specific&order=relevance+desc&bug_st atus=__open__&product=Xen&content=

XenSource certainly wanted to give a warm fuzzy to Microsoft, and bend over and take anything MS would give them:
http://www.linuxworld.com.au/index.php/id;16908928 92;fp;2;fpid;1
http://www.xensource.com/partners/microsoft_resour ces.html

XenSource will not work with VMware on standards, since XenSource is in the backpocket of Microsoft. Easy as that.

XenSource is not Open Source. It is out for money and nothing more, like all Corporations

Right tool...

[suggsjc]

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.

Re:Right tool...

[bogado]

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.

Re:Right tool...

[Anonymous Coward]

I'm not against proprietary software, it's just that they have NO BUSINESS asking ANYTHING from an opensource maker.

Re:Right tool...

[andphi]

I don't know about good, but evil appears to have an established definition: http://catb.org/esr/jargon/html/E/evil.html It is, of course, not everyone's definition, but MS products tend to have a high Evil-to-'Good Thing' ratio.

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

Re:What does VMWare have anything to do with this?

[InsaneGeek]

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.

http://news.com.com/VMware-friendly+change+likely+ for+Linux/2100-7344_3-6061019.html

Re:What does VMWare have anything to do with this?

[Lissajous]

XenSource doesn't have a business to protect?
That'll be why Frank Artale is the vice president of business development at XenSource.
That'll also be why Microsoft and XenSource have joined forces to aid server virtualization, will it?
(FTA - http://www.eweek.com/article2/0,1895,1990366,00.as p )

fleshing out the question

[rodentia]

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?

Re:fleshing out the question

[mrchaotica]

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?

Well, that mixed metaphor sure came out of left field!

Re:fleshing out the question

[Anonymous Coward]

VMWare is owned by EMC, so they aren't trying to get Orcale to offer up cash.

Re:fleshing out the question

[RabidMonkey]

did someone go fishing on the weekend?

or just too much Shark Week (tm)?

Re:fleshing out the question

[smallpaul]

Is it possible VMWare is trolling Oracle for an offer, playing hardball like this?

An offer of what???

Re:fleshing out the question

[SpaceLifeForm]

An offer to endorse Xen. Remember, Microsoft has divorced themselves
from Xen. I'd really like to know who the 'neutral third party' is.

I have a hunch they are not so neutral.

accrodnig to sicentists . .

[Sigg3.net]

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

Re:Who cares.

[argoff]

I'm loosing patience with propriatary software vendors who embrace doing the minimal amount of free software necissary to hold back free alternatives. They're getting washed over, and they deserve every bit of it.

OT: Is it hard to start using virtualization?

[DoofusOfDeath]

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?

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

[teh_chrizzle]

no, you can use VMWare server fairly easily on ubuntu and load pretty much any distro you want.

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.

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

[FellowConspirator]

I had used VMWare way back when and it was pretty simple.

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

lwn.net has a couple of articles about this

[cortana]

• The VMI virtualization interface
  
• Linux team tells VMware and Xen to get their acts together

Maybe..

[bruno.fatia]

Maybe they should do business with MycroS0ft instead !

Re:Maybe..

[Lissajous]

They are - FTA http://www.eweek.com/article2/0,1895,1990366,00.as p

Re:What does VMWare have anything to do with this?

[mrchaotica]

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!

Typical.

[pb]

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.

[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:Typical.

[Anonymous Coward]

Of the two, only Xen is open source though so saying that "only Xen" could use it is being disingenuous at best.

Picking the VMWare approach would lead to yet another area in Linux where the dominant solution is a non-free one (eg: ATI & Nvidia closed source 3D drivers). It will be interesting to see how committed the kernel devs are to the freedom of their code, as to whether they pick a proper al-open source solution, or an inferior and primarily-closed source one.

Re:Typical.

[0racle]

Ah yes the essence of Free software. Try and force people to use it and call it Freedom.

Re:Typical.

[azhrei_fje]

VMware wants the Linux kernel to support a closed-source interface with an API that is not subject to change.

As Greg KH pointed out in his keynote at the recent 2006 Open Linux Symposium (mid-July), closed-source kernel modules are illegal and the kernel developers will do everything they can to prevent them. Besides the fact that they're illegal (in the view of many of the top kernel developers who would be responsible for approving the patches), they also consider them unethical. So even if they were somehow persuaded to include such an API from the legal standpoint, they find it morally reprehensible and would likely refuse on those grounds.

The folks at Xen aren't much better. They think an open source implementation is good, but as you point out, they want it tailored just for them. Linux has always been about choice, so I doubt that viewpoint will prevail either.

Instead, there needs to be a middle ground between these two extremes, or the Linux kernel will never get a hypervisor.

Re:Typical.

[ebuck]

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 environments and perform the "integration" themselves on the client-side.

Oracle is a software company with resources that most other software companies would only dream about. If it was critical to Oracle's success, they wouldn't be clamoring about others needing to do it, they'd do it themselves.

Re:Typical.

[cortana]

No one is forcing anyone to use anything.

Do you think that Linus should be forced to accept the VMI patches into his kernel?

Re:Typical.

[iburrell]

Except that VMI is not a closed-source interface. The VMI interface is an ABI specification that any hypervisor can use. It basically replaces the privledged instructions with calls to a memory block that the hypervisor sets up. The hypervisor can make them calls to the hypervisor. On a virtualized processor, it could leave them alone. Or if there is no hypervisor, the kernel can run natively. There are already open source hypervisors that use VMI. L4 is being used as a hypervisor using VMI. They also have a technique called pre-virtualization which replaces the priviledged instructions in a binary OS (ie Windows) with the VMI calls to allow them to be virtualized without patching the source like Xen (and normal VMI) requires.

Greg was talking about the modules that VMware distributes for the host-side device drivers. They are distributed as proprietary source which need to be compiled for the local kernel.

Re:What does VMWare have anything to do with this?

[Lissajous]

Maybe the reason that VMware is so peeved over this is that XenSource and Microsoft have forged a strategic alliance, so this would be yet another blow against VM, helping them out of the door of the virtualisation market.

Not Surprised

[bensch128]

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

Ego

[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

[jellomizer]

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 controlled. There is a boss who makes the final decision of right or wrong, and if you go Well I will make an other app that does the same thing my way chances are you will see a bunch of lawers at your desk the next day. The motivation for closed source applications are getting your pay, and the attempt to get more.
Neither is more right or wrong just different.

Re:Ego

[Lissajous]

While the warm and fuzzies are indeed why many get involved in OSS, it's not the whole reason behind it. OSS is a perfectly valid business model, and once it becomes a business, then the ego is (or at least, should be) more professionally controlled. There is definitely a boss who makes the final decision of right or wrong.

As soon as it becomes a business, the difference lies in how you make your money out of the software that you write, not whether you make the money.

Re:Ego

[aevans]

Are you kidding? 50% of websites probably use Xen, whether they know it or not. Data center market penetration isn't everything. The data center market percentage usage of virtualization software is about nil.

Re:What does VMWare have anything to do with this?

[Bacon Bits]

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.

Re:What does VMWare have anything to do with this?

[leuk_he]

Xensource 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 the difference to the linux kernel are and what the pro-cons of the different solutions are, and i bet they are also not clear yet to the kernel devs as well.

Re:What does VMWare have anything to do with this?

[InsaneGeek]

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 resier to use ext3 specific extentions, you could tunnel all network communication inside a telnet session, but IS IT SMART?

Ever think that maybe one might have a feature set that the other doesn't? Ever think that maybe someone has a different thought than Xen? Ever think that maybe some other opensource project could do something better than Xen? Are you really this short-sighted?

Long history of wheel reinvention

[Kadin2048]

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.

Re:Long history of wheel reinvention

[hacker]

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 existed at that time. It was a culmination of the GNU project's efforts, wrapped around the Linux kernel because the GNU kernel wasn't functional at that time.

Please don't confuse Linux (the kernel) with (GNU)/Linux (the operating system) in this way. It only makes the situation worse when the media gets involved and pollutes it for the masses who don't understand the big picture.

Re:Long history of wheel reinvention

[Eunuchswear]

What rubbish.

GNU/Linux is a clone of Unix.

Re:Long history of wheel reinvention

[Schraegstrichpunkt]

Have you used Unix and, for example, Debian? They're very dissimilar.

Re:Long history of wheel reinvention

[indigoid]

they sure are different. Debian works!

every time I try to use Solaris' (2.6, 7, 8, 9, haven't had a chance to try 10 yet) /usr/bin/sed it segfaults. /usr/bin/grep lacks the very useful -q option. etc, etc, etc...

the real wtf is that solaris has perfectly functional versions of both of the above in /usr/xpg4/bin. as such the first thing I do on a new Solaris system is fix my profile to have said directory first in $PATH.

Re:Long history of wheel reinvention

[Eunuchswear]

Have I used Unix?

Yes.

Very dissimilar?

Do a man 2 fork on SVR3, SVR4, linux, bsd. Tell me what the biggest difference is.

Try the same on VMS, CMS, Vulcan, George III, Guardian, Multics...

Do you know what Unix is? Debian GNU/Linux is a Unix, Debian GNU/BSD is a Unix, arguably even Debian GNU/HURD is a Unix. It's a Unix if it has a Unix syscall interface, filesystem and utilities.

Part of the problem: Xen isn't baked yet

[postbigbang]

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.

Re:Part of the problem: Xen isn't baked yet

[Anonymous Coward]

Wtf is up with all the food analogies? Is this some sort of astroturfer code?

Seriously. Xen is open source. VMWare isn't. Xen wins, VMWare loses. That's all there is to it.

Re:Part of the problem: Xen isn't baked yet

[lgarner]

The better product wins, that's all there is to it. I don't care if it's open-source or not. All that matters is how well it works and how much it costs. At the momene, we use a lot of VMWare and I don't recommend Xen to anyone.

Re:Part of the problem: Xen isn't baked yet

[billstewart]

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 client, you need VMWare as a server.

After you openly publish the SQL*Net protocol

[Anonymous Coward]

Don't throw stones here Oracle. Where is "FreeTNS"? Guess that's why I keep other database software using "FreeTDS".

Re:What does VMWare have anything to do with this?

[InsaneGeek]

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.

they should try SUN zones

[vspinner]

they work great, simple, easy and fast - and best of all - they come with support and are free

VMMs

[thermostat42]

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?

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

[vhogemann]

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.

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:There isn't already a "default" interface?...

[Wesley Felter]

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

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

[octopus72]

Xen and VmWare should join forces in architecturing common paravirtualisation interfaces, because it's an opportunity to get it engineered in a right way. Let's not forget UML which is a slightly different approach (port of linux to itself to exist as a usermode proccess).

The question is (I didn't understand that from the text), if this will enable them to run unmodified guest OS's (as current Windows, Linux...) with such low level access from the host OS, or they still need customizations?

Btw. one simple example of such API is NTVDM, a DOS virtual machine which can run some DOS games/apps in native speed under XP/W2K (of course it is incompatible with many DOS progs). DOS apps behave like a dedicated operating system in many respects - they hook to DOS, BIOS and TSR's (interrupts) where possible, e.g. for accessing file system, simple memory allocation or restoring shell after finishing, but they still run in real mode with full access to hardware and usually full control of the machine - comparable to Win9x OS series.

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

[Anthony Liguori]

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, updating a page table on a fork may require, let's say, 1,000 interactions with the hypervisor. By making a small change to the guest (paravirtualization), this operation may only take one interaction.

Paravirtualization is still useful in the presence of hardware virtualization which is why this debate is so important. It's very relevant to future hardware.

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

[Anthony Liguori]

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 decision to use the normal instructions when the hardware catches up.

FWIW, I suspect that SVM is probably already pretty good because of the tagged TLB.

Re:What does VMWare have anything to do with this?

[Lissajous]

Yeah - timeline runs like this. April 13th...(in your article)
"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 that a general kernel-to-virtual machine interface is a better thing than a Xen-only one," Morton said.

XenSource and VMware both are fine with the change, but VMware gets a place at the table it lacked before. "

July 18th - XenSource and MS announce a partnership.

August 1st - Big discussion on /. about how XenSource and VMware are butting heads.

I don't see where VMware getting antsy about it's two main competitors in the field getting together isn't an issue?

Errrr... what?

[Ayanami Rei]

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.

Re:What does VMWare have anything to do with this?

[InsaneGeek]

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 agreement, that are still unresolved.

Re:What does VMWare have anything to do with this?

[quanticle]

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 trouble and expense of getting a support contract?

Re:What does VMWare have anything to do with this?

[Anonymous Coward]

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.

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:No, it's pretty easy.

[Anonymous Coward]

Trying to use decoder ring... FAIB - Fairly Awful In Bed?

Re:No, it's pretty easy.

[idlemachine]

No, you want your GNU decoder ring: "Free As In Beer".

Re:No, it's pretty easy.

[Anonymous Coward]

[...] or you can download pre-configured virtual machines [...]

See TwikiVM for the fastest wiki installation, ever.

Configuring it takes a bit longer, if you're into graphics, but if you just want to start adding content it takes about 5 minutes to boot it up and connect to it via a browser and get going.

Re:What does VMWare have anything to do with this?

[Lissajous]

But the problem didn't really exist publically before then, did it? In April, VMware and XenSource were both allegedly "fine" about the change. Greg Kroah-Hartman only announced the problem last week *after* the alliance had been announced. Now there's going to have been problems either side of the dates, but I really don't think that XenSource ran away to play with MS just because VMWare joined the club, do you?

Now I really don't want to sound like a typical /. anti-MS troll, but I can think of harder ways of MS winning the marketshare than buying off XenSource and causing a big dissention in the linux virtualisation camp.

Re:What does VMWare have anything to do with this?

[InsaneGeek]

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 go with a Xen specific option, if you want something stable that won't require constant changes use a standardized non-specific option that favors neither Xen, VMware, Virtuozo or any other. Why should we choose an option specific to Xen or VMware, how about one that supports both equally well, doesn't require major major changes to the kernel everytime one wants to do something new because the interface was written specific to only one, it only makes sense; the only real reason I can think of objecting to a generalized VM interface rather than having everyone use a specific VM interface coded to a certain product is: that person has a bias for their product to be better than the other, not by out coding them but by stacking the cards in one direction so that others can't be better than the one they are supporting.

Are you kidding?

[Moraelin]

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

Re:What does VMWare have anything to do with this?

[InsaneGeek]

If they were fine about the change, than it would have happened months ago, it would have been done already and people would have been coding to what was agreed to and moving on already.

Personal opinions

[kscguru]

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

[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

[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

Re:Personal opinions

[Anonymous Coward]

Honestly, if there was a single Free hypervisor that worked with VMI (and L4 doesn't count ;-)), VMI would already be in the kernel.

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

Re:Personal opinions

[beeblebrox]

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 virtualization going on. This would be very very high on my priorities when deciding on which virtualization solution to use.

Re:Personal opinions

[Anonymous Coward]

And which of the two solutions - Xen or VMware use FreeBSD as the host OS?

VMware has had YEARS to do that. Xen hasn't done it, but the sourcecode is being patched TO support FreeBSD.

When VMware bothers to support FreeBSD in host mode, then I'll start caring about VMware.

Re:Personal opinions

[Anthony Liguori]

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.

Re:Personal opinions

[Anonymous Coward]

Many of us don't even want Xen to use its own interface

Interface? Such a thing may be said to exist, but where's
the documentation?

I have successfully written device drivers against the
Xen Hypervisor API. The Xen documentation for the so-called
API ranges from non-existant to out-of-date to horrible.

If you want more people to adopt, take some time to document.

Then re-factor your documents and incrementally improve them
as the Xen tree moves forward.

Re:Personal opinions

[kscguru]

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

Re:Personal opinions

[cookd]

I would vote to make it configurable.

You obviously recognize the times when it would be valuable to have the guest be completely oblivious to the fact that it is being virtualized, so I won't go into that side of the argument.

If the guest knows that it is running virtualized, it can optimize itself accordingly. VMWare can emulate a PIT, sound card, IDE port, ethernet card, video card, etc. well enough that the guest can load standard drivers and run well. Or it can tell the guest "yes, you can use the driver for a real ethernet card if you want, but you can get 10X better performance if you just do this instead..."

The interface specification for an ethernet card is a very good interface for OS to hardware communication. It turns out to be extremely inefficient as an interface between OS and a host, involving many expensive context switches, state machines, hardware emulation and translation, etc. If the OS (or at least the driver) is aware that it is being virtualized and knows how to communicate with the host, performance can be seriously improved and all kinds of nifty features become possible.

Re:What does VMWare have anything to do with this?

[araemo]

But the problem didn't really exist publically before then, did it? In April, VMware and XenSource were both allegedly "fine" about the change.
And if you read the current article, they're both still 'fine' and 'working' toward a 'good technical solution'.

Think Xorg vs. XFree.

[WindBourne]

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.

Re:What does VMWare have anything to do with this?

[mrchaotica]

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 that was exclusive to VMWare also. And since (according to the summary) "the goal is to develop a single interface for virtualization solutions in the Linux kernel," your point that they should just use separate interfaces is irrelevant (even if it might have merit).

The point I was trying to make was that there was no non-technical reason why VMWare couldn't be changed to Xen's design, but (I implied) that since there could be legal issues (patents or otherwise) that would prevent Xen from changing to VMWare's design, Xen's design should be chosen in order to avoid creating a proprietary "standard."

Re:Support for perfect software

[Anomalyst]

if you are reasonably confident that the software you just downloaded is perfect, why on earth would you go through the unecessary trouble and expense of getting a support contract?

I realize the question is mostly sarcastic+rhetorical, "perfect" for your environment is not "perfect" for my environment. But to answer your question:
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.

Re:What does VMWare have anything to do with this?

[gbjbaanb]

I refer the honourable poster to the answer someone else gave a few moments ago: http://linux.slashdot.org/comments.pl?sid=192771&c id=15824606

Re:What does VMWare have anything to do with this?

[smallpaul]

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 that a general kernel-to-virtual machine interface is a better thing than a Xen-only one," Morton said. XenSource and VMware both are fine with the change, but VMware gets a place at the table it lacked before. "Anything that levels the playing field for different people -- that's going to be good for everyone, but certainly good for us as well," said Dan Chu, the senior director of developer products at EMC subsidiary VMware.

I get the strong impression that Xen is the party trying to play the monopolist in this game. But now that ties with Linux vendors may cool a bit after their cozying up to Microsoft, they may not find that as easy to push through.

Is that bad?

[PenguinX]

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.

Re:What does VMWare have anything to do with this?

[mrchaotica]

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 VMWare is at least making noises about going in the right direction. VMWare working on one by itself is still the wrong solution; what needs to happen is that VMWare and Xen engineers work together on it to make an interface that doesn't fit either product perfectly (since that's impossible if they use different designs), but fits both "well enough."

Re:What does VMWare have anything to do with this?

[InsaneGeek]

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 be??? I think you can make the small mental leaps as to implying people to use Xen's interface (you can make those small leaps can't you?)

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). That way Xen, VMware, or any other can use it; do something different without requiring constant changes.

And you continue to be uninformed, VMware had no technical design boundries hampered by patents, etc they wanted a stable one that anybody could use, go back and read rather than randomly speculate that VMware was trying to make an interface that only their product could use.

Next time just read a little before posting.

Re:Support for perfect software

[linuxrocks123]

Out of curiosity, what OSes / applications were running to where you needed > 64 virtualized NICs on that host?

Re:Support for perfect software

[Anomalyst]

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.

You Stallmanist!

[billstewart]

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

Re:You Stallmanist!

[Schraegstrichpunkt]

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/Linux is the most popular combination of the two.

I tend to refer to the specific distribution that I'm talking about. Debian and Mandriva, for example, are very different and often should not be grouped together in a discussion. If I said, "Linux has a brain-damaged set of filesystem permissions in 'paranoid' security mode," I would be wrong, because Linux doesn't have a "paranoid" security mode. If I said "GNU/Linux", I would still be wrong. If I said "Mandriva", I would be correct (at least semantically).

As a related note, the ordering of "GNU/Linux" is significant. Like "3/4" can be pronounced "3 over 4", "TCP/IP" can be pronounced "TCP over IP" or "TCP on top of Linux", and "GNU/Linux" can be pronounced "GNU over Linux" or "GNU on Linux".

Re:You Stallmanist!

[billstewart]

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, then v7 with Bourne Shell (and csh, and later a variety of bsh and ksh versions, Adventure Shell, etc.), then System III, VENIX, XENIX, several AT&T 4.x, 4.1BSD, System V, VR2, VR2.0p beta, a bunch of SunOSes on 68K, 386i, and Sparc platforms, later Solaris, at least three different windowing systems on Sun (not counting different versions of X - I'm talking things like NeWS), a number of dodgy Unix ports to IBM and Amdahl mainframes, the AT&T System V/MLS multi-level secure Unix system, lots and lots of POSIX certification stuff, V8, several different SVR4 variations as it was fractionating, 4.3BSD, Onyx, QNX, Pyramid, Symmetric, the AT&T 7300 Coherent things, a wide range of 3B20, 3B2 and followons, and then there were a bunch of things I dealt with on paper for evaluation but didn't get to do hands-on with, like Masscomp, Convex, Perkin-Elmer and a bunch of other real-time vendors, actually read the 4.3BSD book that's on my shelf, and that doesn't count the non-Unix-like OS's I've dealt with or the N different Unix-like environments I've used on non-Unix OSs or various post-Unix things Rob Pike built. Eventually Linux showed up, though I probably didn't play with it until after I was done with SVR4 versions in the mid-90s. I've known a number of the Cygnus people from years before they started Cygnus, played magtape frisbee with ESR, made bizdev proposals to Transmeta, seen the "we are under attack" email train nearly live, had RTM's father crack into my computer accounts, probably didn't actually meet RMS until the early 90s, though I've known Len Tower (and emacs) a lot longer.

The GNU stuff was very helpful in porting Unix-like environments to open source, and was good motivation for a lot of people, but the BSD work was also really critical, and so was the X Window System effort - "mechanism not policy" may not be the best policy, but it's allowed a lot of very different window manager development. GCC has been a really useful tool - and it couldn't really have happened without the Portable C Compiler before it. A lot of the userland tools are GNU versions of traditional Unix tools these days, but that's not that critical for most applications, or for differentiating between different Linux distros; things like file systems and window managers and TCP/IP stacks and packet filtering are at least as important.

Re:You Stallmanist!

[Schraegstrichpunkt]

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 certain cases. Shell scripts are one such case, where you care mostly about the shell you're using and whether or not you have GNU coreutils in your $PATH, so I disagree that "GNU/Linux" is "purely a credit ploy".

Part of the issue for me is that I feel that Linux-based operating systems should be called something other than just "Linux" (which is just the kernel...and probably userland tools like insmod and iptables). "GNU/Linux" is as good a name as any for this purpose. Well, it would be if it weren't for the backlash against it. Thank you once again, Linus.

I don't use "GNU/Linux" all that often anyway. I find "Debian sarge/amd64", "Linux distros", "Linux kernel", "the kernel", "userland", etc to be more precise and less politically-charged these days than both "Linux" and "GNU/Linux".

Re:You Stallmanist!

[billstewart]

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.

Re:What does VMWare have anything to do with this?

[mrchaotica]

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 software works to be compatible with the new "standard." In other words, adopting VMWare's standard would be like adopting one of Microsoft's "standards" -- because one company designed and controls it, that company has an unfair advantage.

In contrast, because Xen is open source VMWare automatically has the oppertunity to see what Xen is doing and give their input to the project. If Xen is resisting that, well then the Xen people are being assholes.

Look, I don't disagree that Xen is being obstinate, but I refuse to jump to the conclusion that VMWare isn't being so also. Tell you what -- show me some evidence that VMWare is making a good-faith effort to have community input to their standard, and are willing to make compromises (including some that cause VMWare to have to be changed to become compatible) instead of insisting that the interface perfectly accomodate them, and I'll reconsider my position.

Re:What does VMWare have anything to do with this?

[InsaneGeek]

How about link #1: http://www.eweek.com/article2/0,1895,1996904,00.as p

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.

GNU, Linux kernel, etc.

[Kadin2048]

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.

Re:What does VMWare have anything to do with this?

[houseofzeus]

It's hard to make a collaborative standard when one party (Xen) isn't interested in collaborating at all.

Re:What does VMWare have anything to do with this?

[mrchaotica]

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

Unfortunately, your quote comes right after the part of the article where they basically say that VMWare won.

Re:What does VMWare have anything to do with this?

[mrchaotica]

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.

"It's an ABI [Application Binary Interface] rather than an API. It has some nice technical properties, in particular with regard to enabling the same kernel to run virtualized or native. Xen supports this too, but through a different mechanism, in which the kernel either links with Xen or with a shim (that offers the same hypercall API) that allows the kernel to run native," he said.

In contrast, Xen used an open API, which allowed the kernel developers to see and work with the code that will virtualize the kernel.

XenSource is entirely justified in objecting to something like that!

Re:What does VMWare have anything to do with this?

[InsaneGeek]

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?

Apples, Meet Oranges

[KagatoLNX]

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.

Re:Apples, Meet Oranges

[Anthony Liguori]

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.

You clearly haven't ever written a driver for Xen. The Xen drivers are far more complicated than normal hardware. This is mostly do to XenBus but that's a whole other conversation....

However, in addition to this, Xen caters to situations with tiny realtime handlers running along side the a larger interface OS.

What do you base this claim on? I can write a very tiny OS that runs with emulated hardware is considerably less space than what it takes to run under Xen.

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.

Uh, you do realize that there are more Xen hypercalls than VMI exits? There are some VMI exits that aren't strictly needed (because they are ops that can be trapped and emulated) but the reasoning behind including these in VMI was so that one could write a very minimialistic hypervisor that did no instruction emulation (doing emulation correctly is *very* complicated).

You also realize that the Xen hypercall API varies greatly across architectures right?

So you're way off base on all your assertions. The real history of Xen is that it is based on the Nemesis exokernel which was a research project out of the University of Cambridge. Long before everyone was excited about hypervisors, a number of research exokernernels/microkernels were capable of running Linux as a guest (L4, K42, and Nemesis). This "high level" interfaces that you're referring to are actually part of the nemesis API (event channels, domains, etc--although grant tables is a new concept that was pretty recently introduced).

Now, Xen paravirtual is different from other forms (like what appears in Denali or even PowerPC) because it makes the guest aware of these higher level APIs. The problem is that this makes maintaince a nightmare because the changes to the guest are so extreme.

So, after two years of this guess what's happening? Xen is ditching writable page tables in favor of shadow paging and adopting Rusty Russell's paravirt_op architecture. paravirt_op is very similar to VMI (it's actually a subset right now). The idea is that this isolates the complex Xen API from the guest to reduce the mainaince burdern (which is way too high right now). There are going to be cases where details of the Xen API must escape the current paravirt_ops but we're going to examine these on a case-by-case basis and try to reduce that as much as possible. Contrast that to the former approach where there was basically no attempt to isolate the Xen API from the guest.

The problem with VMI is not the fact that the API is too low-level. The real problems center around whether a binary blob should be allowed to be injected into the kernel by the hypervisor and the desire of the kernel community to have a stronger relationship between the kernel and the hypervisor.

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?

Re:Inside information on XenSource

[Anonymous Coward]

Who would possess you to write such a nasty (but true) comment? Who?
Saaaattttttttttaaaaaaaannnnnnn, perhaps?

And BTW, GBTW! SWAK! WWJD, WWLRHD (and what am _I_ going to do to you after you finish your unpaid overtime, you bad, bad little monkey!?)

Re:Inside information on XenSource

[Anonymous Coward]

or Xenu, perhaps in this case :)

Re:Inside information on XenSource

[Anonymous Coward]

Every single allegation in this article is outdated by at least six months. No San Francisco apartment, not many VPs, no church connections, totally different tech support, different IT team.

WTF is this argument even about?!

[bluefoxlucid]

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.

Re:What does VMWare have anything to do with this?

[mrchaotica]

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!

Re:What does VMWare have anything to do with this?

[InsaneGeek]

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

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

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

http://news.com.com/VMware-friendly+change+likely+ for+Linux/2100-7344_3-6061019.html?tag=nefd.top where the current stable kernel developer likes VMware's solution of a non-Xen specific implementation, rather than Xen native and everybody else uses shims into Xen to get into the kernel.

Then come back here, after you are informed and not speculating anymore, realizing that when the current stable kernel developer says he agrees with VMware's methodology (a common VM layer rather than a specific one to Xen), that you were seriously incorrect. That you are saying that the person responsible for the stable kernel is incorrect because it goes against the philosophy of the kernel. You are just so incorrect it's actually hurting me.

Re:What does VMWare have anything to do with this?

[mrchaotica]

You know, in addition to reading that eWeek article you posted, I also read the paper presented at the 2006 Linux Symposium, 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.

"ABI" stands for "Application Binary Interface." In other words, it allows linking a binary blob into the kernel.

As I said before, a stable ABI is what the kernel maintainers have been denying to nVidia and ATi -- and for good reason! Why should VMWare be treated differently?

the current stable kernel developer says he agrees with VMware's methodology (a common VM layer rather than a specific one to Xen)

Here's the exact quote (from your second article):

"From a high-level design perspective, I think that VMware's point is a good one, and that a general kernel-to-virtual machine interface is a better thing than a Xen-only one," Morton said.

That's not the same thing as "agree[ing] with VMWare's methodology." "VMWare's point" could equally well apply to having a general API, which is not the same as what's actually being done.

Re:What does VMWare have anything to do with this?

[InsaneGeek]

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 specific hypervisor version. It would be like having to recompile bash everytime you upgraded the kernel to the new specs, a standardized ABI for the guest kernel keeps you from having to do that. It's not specific to VMware, it would be beneficial to everyone (unless you really want to recompile every kernel in every VM everytime you patch your hypervisor). So what really is being debated is the implementation details of that proposal (do memory this way not that way), not the proposal of VMI itself.

If it really was what you seem to think it would be, don't you think that when they proposed it that someone on the kernel mailing list would have been jumping up and down about it? That would be something that someone would have mentioned by at least the 3rd message. Check the thread yourself: http://thread.gmane.org/gmane.linux.kernel/388353

Sounds like typical Linux crap

[NateTech]

No surprises here... people arguing over API's and the kernel. Gee, read kernel-traffic lately?

Re:What does VMWare have anything to do with this?

[mrchaotica]

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

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 specific hypervisor version.

You say that as if it's only one, simple thing. It's not. APIs and ABIs are two completely different things; in the case of Linux, the first is OK but the second isn't.

It would be like having to recompile bash everytime you upgraded the kernel to the new specs

No, it would be like having to recompile your kernel modules every time you upgraded the kernel, which is entirely reasonable.

If it really was what you seem to think it would be, don't you think that when they proposed it that someone on the kernel mailing list would have been jumping up and down about it? That would be something that someone would have mentioned by at least the 3rd message.

Actually, several people did mention it. Zachary, the guy from VMWare, rather artfully avoided the questions and they didn't notice. For example:

On Mon, 2006-03-13 at 10:30 -0800, Zachary Amsden wrote:
> Arjan van de Ven wrote:
> >> The interface we propose we
> >> believe is more powerful, and more conducive to performance
> >> optimizations while providing significant advantages - most
> >> specifically, a single binary image that is properly virtualizable on
> >> multiple hypervisors and capable of running on native hardware.
> >>
> >
> > that is mostly an advantage in the binary would though.. less so in the
> > open source world.
> >
>
> It is an advantage for everyone. It cuts support and certification
> costs for Linux distributors,

that I'll buy
> software vendors,

that I'll buy a lot less except those with kernel modules (which is
evil ;)
> makes debugging and
> development easier,

that I don't buy; a fixed interface tends to make debugging harder not
easier since you can't change it to add more information

> and gives hypervisors room to grow while maintaining
> binary compatibility with already released kernels.

that I buy for binary only hypervisors. But in an open source world I'll
buy this a LOT less as being relevant.

To which Zachary replied:

This is not about the open source versus the closed source world. It is about the real world, where customers want to make as few changes as possible to a working and already deployed system. If they have to recompile a kernel just to get their system to run again, that is a pain point that is easily avoided.

Notice how he did not address the issue of the GPL at all, but rather just dismissed it? I think it most certainly is about "the open source versus the closed source world," and that VMWare has managed somehow to pull one over on the kernel devs.

Re:What does VMWare have anything to do with this?

[InsaneGeek]

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

Wait so you are saying that if I compile up kernel 2.6.x that has a standardized, stable ABI for a second systems kernel that when I upgrade to kernel 2.6.y that it's close to a GPL violation, even though I'm not using anything non GPL compliant? Are you truely this dense?

No, it would be like having to recompile your kernel modules every time you upgraded the kernel, which is entirely reasonable.

No it would not be like having to recompile your kernel modules every time you upgraded the kernel. I could no longer be testing kernel 2.6.x if I upgrade anything. Everything has to have the exact same kernel patches. Not recompile, insert new virtualization patches specific to the hypervisor onto any old kernels running in the hypervisor. What part of this do your not understand?

You say that as if it's only one, simple thing. It's not. APIs and ABIs are two completely different things; in the case of Linux, the first is OK but the second isn't.

No duh, they are two different things. One is a specification everyone must code to, the other allows a fully GPL compliant kernel to directly talk to another fully GPL compliant kernel, period. If you don't do that you must recompile the kernel everytime you upgrade the hypervisor (the way Xen is today). Do you honestly believe that is a sustainable, maintainable, option? Do you truely believe that it's not in the best interest of Linux to be able to run 2.16.20 & 2.16.22 & 2.17.1 in the same hypervisor? Do you know how stupid that really is?

Notice how he did not address the issue of the GPL at all, but rather just dismissed it? I think it most certainly is about "the open source versus the closed source world," and that VMWare has managed somehow to pull one over on the kernel devs.

Neither did the questioner really address anything about the GPL, he said that some areas closed source would get a new benefit, where open source already had the same benefits. Unless your intent is so zealotist to make intentional out-of-the-norm roadblocks against anything closed, actually causing linux in general pain. There is no GPL violation at all, none whatsoever, elsewise you could have come up with a MUCH better example than someone saying that opensource wouldn't benefit because it already has it. Come on you can do better than that.

Re:What does VMWare have anything to do with this?

[mrchaotica]

Wait so you are saying that if I compile up kernel 2.6.x that has a standardized, stable ABI for a second systems kernel that when I upgrade to kernel 2.6.y that it's close to a GPL violation, even though I'm not using anything non GPL compliant? Are you truely this dense?

No, I'm not. I'm saying that linking binary blobs into the kernel is a GPL violation, and stable ABIs facilitate and encourage that.

Not recompile, insert new virtualization patches specific to the hypervisor onto any old kernels running in the hypervisor. What part of this do your not understand?

What part of "a stable API would mean you wouldn't have to recompile your kernel when you changed your hypervisor (or vice-versa), beacuse they wouldn't be linked to each other in the first place" do you not understand?!

Take your bash example from a while back: bash does not rely on a stable ABI to run; all it requires is a stable system call API. A hypervisor should work the same way, not like a kernel module (which is the way they plan to do it, if they're defining an ABI).

If you don't do that you must recompile the kernel everytime you upgrade the hypervisor (the way Xen is today).

No it doesn't, as I just said.

Do you honestly believe that is a sustainable, maintainable, option? Do you truely believe that it's not in the best interest of Linux to be able to run 2.16.20 & 2.16.22 & 2.17.1 in the same hypervisor? Do you know how stupid that really is?

Your questions can't be answered either "yes" or "no" because they depend on a false presupposition. However, if it were true then of course it would be stupid because it wouldn't be sustainable or maintainable. But it's not true, so the question is irrelevant.

someone saying that opensource wouldn't benefit because it already has it

Read it again. He wasn't concerned merely that open source wouldn't benefit; he was concerned that it would hurt:

that I don't buy; a fixed interface tends to make debugging harder not easier since you can't change it to add more information

Re:What does VMWare have anything to do with this?

[InsaneGeek]

No, I'm not. I'm saying that linking binary blobs into the kernel is a GPL violation, and stable ABIs facilitate and encourage that.

Binary blobs can be GPL compliant too you know, and you do also realize that linking binary blobs into the kernel happens all the time (what exactly do you think glibc does?) God you really are that stupid aren't you.

What part of "a stable API would mean you wouldn't have to recompile your kernel when you changed your hypervisor (or vice-versa), beacuse they wouldn't be linked to each other in the first place" do you not understand?!

Take your bash example from a while back: bash does not rely on a stable ABI to run; all it requires is a stable system call API. A hypervisor should work the same way, not like a kernel module (which is the way they plan to do it, if they're defining an ABI).

That's exactly the point, without glibc you would have to recompile bash everytime you recompile the new kernel, glibc uses a standardized ABI interface to talk to the kernel. Why looky here, old kernels can talk to the VMI layer via a standardized API and talk to the kernel via a standardized ABI. You'd think that someone intentionally thought about that... hmmm....

No it doesn't, as I just said.

Ok rather than just saying you have to recompile a module, prove to me why that would not be the case. Why exactly do you think programs talk to glibc rather than the kernel itself? Have you ever done any actual development, or at least thought about things for a little while?

Your questions can't be answered either "yes" or "no" because they depend on a false presupposition. However, if it were true then of course it would be stupid because it wouldn't be sustainable or maintainable. But it's not true, so the question is irrelevant.

It is true, and you merely saying that it isn't doesn't prove anything. If the kernel never, ever changed it would be the case, but the kernel is dynamic. To fit into your thought process would require the kernel to be as slow moving as glibc, have you ever dealt with systems when they did any major changes to glibc? Is the light coming up now? Do you see what you are saying?

Read it again. He wasn't concerned merely that open source wouldn't benefit; he was concerned that it would hurt

Again, you are decrying horrible, evil things, close to GPL violations and that is the best thing you can come up with? That it makes debugging harder? No statements that it's against the GPL, no statements that it's against the philosophy, no nothing. What you bring to support argument is a statement that it makes debugging harder... dear god, just stop. If that's the criteria.... you are a true idiot, a monumental idiot... no gpl statements, nothing of the sort, just a statement it makes debugging harder... that proves it you must NEVER have done any programming in your entire life. DO YOU NOT THINK THAT ARGUMENT COMES UP IN ALMOST EVERY OTHER PROGRAM KNOWN TO MAN? If that's the requirement, than every single program out there, that's maintained by more than 2 people would be GPL violators, you are truely an idiot. Just stop going down that rat hole because you digging a huge hole, you've officially crossed into idiot land now.