Why Oracle Doesn't Like VMware

In my travels and customer discussions, this particular topic is coming up more and more frequently.

Now that EMC and VMware and other vendors are encouraging customers to seriously consider virtualizing their more critical applications, it's going to become a increasingly hot topic.

As a matter of fact, I'm now quite ready when I hear the familiar "well, Oracle doesn't support VMware".

Getting to the truth of why this actually might be has proven a bit difficult.  It's not something the Oracle people really want to talk about.

In the meantime, I've put together a list of possible reasons why this could be, and offered a bit of commentary as to the thinking behind it.

So let's go take a look at what could possibly be behind this rather unproductive stance towards customers.

To Start With

I ought to put in a disclaimer here. 

I'm not representing Oracle's official position (or EMC's official position!) in any capacity. 

Just sharing a few thoughts, folks :-)

Paradoxically, I am told that the actual details of Oracle's official support stance towards VMware is somewhat reasonable when you take the time to hunt it down, decompile exactly what they're saying, and have someone explain it to you -- but the general perception from customers is that Oracle really doesn't like people running their products on VMware.

Never mind that their internal developers use it extensively :-)

I also would like to point out that I see Oracle as a hyper-rational company.  Everything they do is for a very clear reason. 

You may not like the reason, but it's always there.

#1 -- Oracle DBMS Doesn't Run Well In A Virtual Machine

Not true.

There's a mountain of evidence that shows a single VMware virtual machine running an off-the-shelf Oracle database scales nicely up to 8 virtual CPUs, uses great gobs of RAM and tens of thousands of transactions per second. 

And, with every new tick-tock of Intel's processor line, it's just getting bigger and faster.

Another point: I'm aware of literally many hundreds of customers who do just this as a normal matter of running their business -- without any drama whatsoever.

Some may push a bit and say "well, there's an I/O tax" or something similar.  There's no denying that a hypervisor adds a tiny bit of overhead to bare metal or native operating systems, but it's quite reasonable, and dramatically outweighed by the advantages that virtualization gives you in other areas.

By the way, Oracle doesn't seem to have any of these concerns if you use *their* hypervisor :-)

#2 -- Oracle Hasn't Seen Enough Demand From Customers To Support This.

I almost sprayed my coffee on the laptop the first time I heard this. 

I put it in the same general category as saying "Oracle hasn't seen enough demand from customers to support Intel processors, or the Windows operating system".

C'mon guys -- get real.  It's 2009.  You can do better than that.

#3 -- Oracle Can't Get The Support They Need From VMware

Well, I didn't choke quite so badly when I heard this for the first time, but my blood pressure did rise a bit.

It's a common tactic in the industry to blame the other guy when you just don't want to do something.  But, in this case, it's just not true.

Now, I work with VMware on a day-in and day-out basis, and I can personally attest that the VMware team would jump through many flaming hoops and crawl over broken glass to support Oracle's customers in any reasonable fashion. 

Same for EMC.  Probably true for other server vendors as well.  So, in my mind, this is a convenient misdirection.

No, folks, I really believe it's something else entirely.

#4 -- VMware Functionality Competes With Oracle DBMS Features

Now we're getting warmer.  Much warmer. 

Oracle hasn't come out and said this to the best of my knowledge, but it's pretty clear to many of us that this is the case.

Let's construct a side-by-sde mental model of two similar Oracle DBMS configurations.

On one hand, we've got a multi-server configuration running Oracle's latest (and most expensive) RAC product.  It's doing load balancing, high availability, and making the hardware function as a giant pool.

Nice.

On the other hand, we've got the same multi-server configuration running the much cheaper Oracle SE on VMware. 

It too is load balancing, offers high availability, and makes the hardware function as a single giant pool.  Many of the management tasks are handled quite well outside of Oracle's domain.

By the way, none of those features can be found in Oracle's hypervisor.  Why would Oracle want any functionality in a hypervisor that's open source?

And VMware brings a few very cool features to the table that Oracle doesn't, like real fault tolerance.  Or Dynamic Power Management.  Or Site Recovery Manager.  The list goes on and on.

Nicer.

Not that anyone I know would ever want their Oracle databases to run fully fault tolerant on industry-standard hardware :-)

And wouldn't it be very surprising if -- for some workloads -- customers saw far more performance and throughput from the VMware / Oracle SE database config as compared to the much more pricey Oracle RAC configuration?

Maybe Oracle could fight it out with VMware toe-to-toe on the finer points of performance, functionality, etc. -- but why bother? 

So much easier to create the impression that Oracle doesn't support VMware, and move on.

Now we're starting to get to a reasonable scenario as to why Oracle would work very hard to discourage customers from using VMware.

People would figure out that just maybe they didn't need the full-boat Oracle RAC, and could do very nicely indeed with the far more cost-effective Oracle SE version.

The result?  The Oracle sales force would have to spend time and effort fighting it out with a VMware-based approach.  And, inevitably, a lot less DBMS license revenue and maintenance ends up in Oracle's pocket.

Ouch.

That might explain a lot, yes?

#5 -- Larry Wants To Own The Stack

Some of the more interesting statements made by Larry Ellison and his team as part of the Sun announcement point to their vision that Oracle could now provide a complete solution "from database to disk".

Now, if that's Oracle's strategic goal, it would be very inconvenient indeed if customers preferred to break up that nice stack with a cloud operating system from VMware, wouldn't it?

To spend all that money on Sun, and not be able to "close the walls of the garden" so to speak -- well, that just wouldn't do in the grand scheme of things, would it?

I don't know if you're aware of this, but when IT vendor strategy guys get together, they talk about emerging stacks, control points, where you want to be open and where you don't, where you monetize and where you commoditize, and so on.

Not to share deep industry secrets here, but it's a very common strategic framework for how IT vendors think about assembling their portfolios.

And having VMware inconveniently show up in the Oracle's new stack with all these radical capabilities just isn't a good thing for Oracle's implied strategy with Sun.

Put differently, if you're Oracle, you don't want a really big and important strategic control point in your stack being owned by someone else. 

That's a bad scenario for Oracle.  However, that's a very good scenario for customers.

Where Does That Leave Us?

At the exact same place that occurs every time a major industry vendor declines to support and embrace an emerging de-facto standard.

The only cure is sustained and overwhelming customer demand.  Sooner or later, vendors do get the message.

As an example, both Microsoft and SAP started out on one side of the VMware support fence, and had to move to the other.  Now it's Oracle's turn, IMHO.

But they're a stubborn bunch over there at Oracle.  If you think back over Oracle's history, you know that they try all sorts of interesting things and hang tough for a while, but tend to give them up quickly if they don't work out.

I think that's the case here -- and here's how you can help speed up the process.

Put the pressure on.  Don't meekly roll over and say 'golly gee, I guess that's that".

Use your voice as a consumer of enterprise IT products to say "hey, I'm in charge here, not you!"

Call them on it -- loudly and publicly.

If you're a customer, and you're hearing this "Oracle doesn't support VMware" story from an Oracle person, a bit of righteous anger might help.

For example, you might try something like this: how dare Oracle attempt to control my IT infrastructure strategy by declining to support software they don't like? 

What's next -- you're going to tell me that you only run on SPARC and Solaris?  (don't laugh ...)

It also might be helpful to get an informal list of larger customers where Oracle has tried this play, and it just hasn't worked. 

I get to meet people who get Oracle support for VMware quite frequently.  And Oracle doesn't seem to give them any unusual grief about it, either.

What is there, a two-tier system for supporting customers with VMware?  If you're a big and powerful IT consumer, you can force Oracle to support VMware, otherwise you're stuck?

Now that just isn't right, is it?  :-)

I'd Really Like To Hear From The People At Oracle

Now, I may be totally off-base here. 

I may have completely misunderstood what I've heard from dozens and dozens of customers around the world.  I may have not seen the latest Official Support Policy Update on their web site.  Or something else that caused me to veer off in a totally incorrect and inaccurate direction.

But I'm not the only one.

So -- good people of Oracle -- please accept my humble apologies if this is the case, and do me the favor of correcting me if I'm wrong here.

I will gladly retract and/or amend any statement made here based on you setting the record straight in a public forum.

Frankly, I think it'd be good thing for you to do -- because an awful lot of your customers are getting the wrong impression!

Comments

[nate]

Unless things have changed in the past year or so(I lead a project for my last company to migrate from Oracle EE to Oracle SE), Oracle SE includes RAC as part of the licensing whereas with EE you pay an extra $20k/proc(list).

Also Oracle SE is limited to 4 sockets(unlimited cores per socket) per cluster. So if you have 4x1 socket SE systems in a RAC, or 1x4 socket standalone Oracle box that's the limit, doesn't matter if your running in VMware or not. One Oracle SE schema cannot span more than 4 sockets.

Also Oracle counts the number of physical CPUs in the box regardless of how many vCPUs are actually running Oracle.

At my last company as well we had Oracle on two different systems running ESX on top of iSCSI(one was for production reporting + sandbox testing+backup), the other was for development + QA). Single socket HP DL385G5s with 16-32GB of ram. Oracle didn't support it since we were running on VMware, and VMware didn't support it because we were only using 1 CPU socket in each system, but it didn't matter, it worked well and it saved a lot in licensing costs both with VMware and Oracle. With the reporting/sandbox system(which shared the same storage as production), we had snapshots going to the reporting DB every night cutting our reporting time from ~9 hours to ~15 minutes(used to use data pump..ugh). Used full physical copies for sandbox testing as it was several weeks or months between requests to refresh the environment, took about 3 hours, down from ~2 days previously. Had a 3rd VM on the reporting+sandbox VM server that took snapshots nightly of the production system in hotbackup mode for RMAN. Since in Oracle SE you cannot run RMAN against the standby database(live at least, DB will spit out an error saying that functionality doesn't exist) like you can in Oracle EE. Our DB consultants wanted to just run RMAN against the primary DB, but I wanted something better.

I had everything related to Oracle installed on our mini SAN, the application itself, the logs and the DB. When I took snapshots I took a snapshot of all 3 at the same time, so I only really ever had to have Oracle installed on a couple systems even if I had DBs on many more than that.

When we migrated from Oracle EE to Oracle SE I used vmware there as well since you have to fully export and re-import the data(then I would swing the mount points back to the original host and fire it up). The first time it took much longer than I expected and we had to roll back at the last minute. The second time it took just as long(one fulltext index alone took something like 10 hours?!), got close to rolling back again, but decided not to, I kept the schemas I had migrated to Oracle SE running on VMware for that day(it was a Sunday, low traffic), and kept the remaining schemas on the original hardware running Oracle EE. Later that night I took the systems down again and migrated the remaining schemas, then switched out the mount points and fired up Oracle SE on the original hardware, worked great.

If my boss at the time would of listened to me we could of saved an extra $150k in licensing and penalties by migrating to Oracle SE earlier (they originally bought Oracle SE One but their consultants installed Oracle EE out of habit and that was of course caught during an audit, then they paid a bunch of $ to "true up" but they didn't read the fine print and was faced with another $80k+ in fines the following year, at which point we decided to go to SE.

I went to a vmware event a few weeks ago and happened to meet up with that same DB consulting company(they have some really good folks there), and asked them what they were using, vmware or Oracle VM? They said VMware, they tried Oracle VM but didn't get very far before encountering some pretty nasty bugs. They did say that they don't(yet) run Oracle inside VMWare though.

A rumor I heard from someone who I trust also mentioned a rumor he heard that Oracle+Vmware were in discussions for a while about releasing a white paper on optimizing Oracle within VMware, and towards the end they discovered that VMware could make Oracle run faster inside the VM than on native hardware on the same system, Oracle got upset and pulled the plug on the whole thing.

My current company mostly uses MySQL, and a bunch of legacy stuff on MSSQL 2000. When I first got exposure to Oracle in 2003 I really didn't like it but the more I used it the more I liked it, and I do miss it. Oracle EE isn't worth the $$ for most people I think, Oracle SE provides an awesome value though IMO. A couple companies ago that I was at we had the world's largest OLTP database in the world(at the time about 15x larger than the next largest which was Amazon I think), I think they still have it too, running on Oracle. Oh the outages on that thing.. they had a really poorly designed application that stored 100x more data than they needed, one of the few places who's data warehouse is a small fraction of the size of production I imagine. I remember Oracle flying out one time to help us fix a bug that took our production DB down for more than a day, their jaws dropped when they found out what we were using it for.. YOUR DOING WHAT?! Even EMC sales guys were telling us they had no customers that were doing what we were doing. Kind of makes you think..

[Chuck Hollis]

Nate

Your comment rocks. You rock. Thanks!

-- Chuck

[Tarry Singh]

Chuck,

I hate to put rhetorical questions upfront as I've worked closer with VMW on this initiative (internally) for the past years than no one else. You don't want to know the details as both parties (VMW and Oracle) were not meeting up at the proverbial bridge to chat up, cuddle and make love.

I am however confused about your "comparison" on RAC vs VMware's HA using Oracle SE versions. There are fundamental differences (and greatly architectural differences) between Oracle RAC and SE with other HA kind of tools. Same applies for the decision that is made when choosing RAC.

1. Decision on price in this current screwed up climate

Oracle EE is just about as much its worth in dollars as VMware is in its pricing policy. When a company comes to cut dollars one of the two goes. When Oracle loses to MSSQL because VMW thought that HA = RAC, then we have pissed folks at Oracle.

When Oracle VM wins over VMware at a SMB client because it is free and gets all of Oracle sweet loving support when you open a TAR, its VMware that loses another customer.

Customers too end up choosing solutions that are totally not good for them. I've seen customers move away from Oracle to MSSQL without doing a CBA. Yes, a Cost Benefit Analysis.

2. Swarm dumbness, group polarization and Cass Sunstein's case

Cass is on Obama's board and has written a great book on "Going to Extremes". A great read. We should push each other to the good extremes and not the bad extremes. And I truly believe that this time around we must not abuse the crowds (un)wisdom to do yet another sale where the customer couldn't see/realize the benefit.

Wrondheadedness is more worrisome than choosing the right party. Choosing Oracle RAC is probably the best thing that can happen to the dataset and in another occasion doing a test on VMware is a perfectly viable option. I also know many customers who have been running Oracle SE on VMware and really not measuring anything and let any discussion go in any direction.

3. Enlightened experts and aggressive sales: We need both in a "truly" working economy

Oracle has a great sales staff and it works excellently. They have great developers who can dish out a great technology and know the internals really well. VMware has good engineers as well who work hard to make their hypervisor work and help apps scale.

Customers must really really really learn (I just have to emphasize it so often, have been doing it for decades) to have their own functiona;/tech requirements and benchmark scenarios ready. They simply don't have one and eventually lose out to a migration to MSSQL or other DB vendor while the case was totally different. Having an expert at the customer end always helps, they do their homework and choose the party without biases.

THAT is CBA. Not abusing the pernicious power of the group(s) that has its own sets of proclivities and doing some tests with what you got. I know one technologist at Oracle (there are many great ones out there) who does that relentless to evangelize Oracle's great technology and funny enough Oracle does have a CBO that tells the DBA to optimize his/her's database. And then after having done the optimization, you can choose or not choose to scale your app on a hypervisor OR go to RAC or do both (there ARE some technical timer glitches there so I hear] and see which of the two/three/more is better, that is doing the CBA on the tech front [after having done the CBA also on the people-side -- very crucial]

Technology has never been the problem.

Disclaimer: I have been an ex-Oracle RAC/DBA admin from version 7.3 thru 10g.

[Gary Watson]

I think they will ultimately support VMware, but they will change their pricing model for VM's such that you don't save any money over the RAC implementation.

By the way, I looked around for you at the Orlando VMware event -- couldn't find you. Are you coming to VMworld?

[Chuck Hollis]

Hi Gary -- thought I dropped you a note, wasn't going to the VMware event in Orlando. Next outing for me is EMC World week after next, also in Orlando.

Don't know about the VMworld event yet -- thanks!

-- Chuck

[Micky]

Funny, buy I can't even get an EMC Sales person to call me back, seems they can't be bothered to sell their products. What is the point of the link on the EMC webpage to Contact Us? Why does the local office say they will have somone call you back and then not do it?

I work at one of the largest consumer goods producers in the world, but EMC cant be bothered.

Maybe they let the sales staff go.........

So much for customer service...............

[Chuck Hollis]

I'm not making any excuses for anyone -- but I can help!

I'll drop you an email!

Update -- Micky, you mistakenly left a bogus email address, so it's going to be hard to get back to you.

-- Chuck

[Chuck Hollis]

Jeff Browing gets into it even more here:

http://oraclestorageguy.typepad.com/oraclestorageguy/2009/05/response-to-comments-from-alessandro-perilli-blog.html

Great reading!!

[Chuck Hollis]

Hi, this is Chuck

I seem to have raised the ire of many people that thought I might be suggesting somehow Oracle SE + VMware is a direct replacement for Oracle RAC.

As we all know, that's not the case -- Oracle RAC has a whole slew of features above and beyond this.

However, not everyone may need all those features. Lower-end Oracle versions running under VMware may offer unique attractiveness for customers looking to consolidate multiple database instances, provide high performance, load balancing, high availability, etc. --

-- Chuck

[Sean Finnegan]

Chuck,

How does today's news of Oracle buying Virtual Iron change your #5 above? Does this acquisition shed new light on the Oracle-VMware support issue?

[Chuck Hollis]

Hi Sean -- timely question, no?

With the news of the acquisition, it's pretty clear to me that Oracle will now try and make a play directly against VMware -- maybe even outside their traditional database world.

The Virtual Iron stuff isn't shabby. I mean, it isn't VMware, but it's not entirely lame either.

Should be interesting!

-- Chuck

[Radim Fiala]

Hi,
sorry for a little bit off topic question (thus vmware related).
If its possible, please enlighten me how you could possibly use vmware´s fault tolerance feature (you mentioned in your article) with Oracle in production environment?
Fault tolerance seemed like killer feature to me - I planned to use it for MS SQL to avoid MS clustering.
I encountered one major obstacle - fault tolerance is only single CPU VM option at the moment...

Regards,
Radim

[Chuck Hollis]

Hi -- sorry for the delay.

Chad -- over at virtualgeek.typepad.com -- is the maestro at these questions.

I hear that initial support is limited to 1 or 2 CPUs -- same as most newer features in VMware -- and then usually expands as the technology and confidence improves.

Could you drop a comment over there?

Thanks!

[Gregory]

Hi Chuck,

I have a question which is more ethical then technical. Is what Oracle are doing to potential VMware customers not considered a coercive monopoly in some way?

Oracle are attempting to prevent customers who want to use their database products on certified platforms from using other virtualization products which in turn is preventing vendors like VMware and Microsoft from being able to compete for sales on virtualization products.

Regards,
Greg

[Chuck Hollis]

Hi Greg

Personally, I wouldn't frame the issue in terms of "ethics" per se, more in terms of corporate culture and strategy.

Oracle believes that it has enough clout to force its own virtualization agenda on its customers. Since Oracle hardly has a monopoly on database technology, or virtualization technology (or anything else for that matter), this does not get into antitrust and monopolistic behavior territory in my book.

Customers are free to use non-Oracle database technology (e.g. SQLserver et. al.) if they don't like Oracle's stance. Or they can choose to work with a 3rd party for Oracle support, as many have. Or simply lie to Oracle about what they're actually doing.

Sure, it's a bad-for-customers stance they've chosen, but customers -- as always -- have the final say.

Thanks for writing.

[J Philip]

I am an Oracle Pro but let me call this a Digtal Pride and I am sure this will come down because VMware is that strong in technology.