Oracle Support on VMware – your Cisco switches and DELL servers aren’t certified with Oracle

So I came across this article last week on Oracle VM and how companies are trying it and how it’s, and I’m quoting here “not half bad”

If I ever come out with my own Enterprise level software and have a couple of public releases under my belt and the best thing I can get in the press is “not half bad”, shoot me.  Seriously.  That’s embarrassing.  Even if you do offer it for free.

So let’s look past the headline and see what the article has to say, shall we?

First sentence “Oracle’s continued refusal to support its applications virtualized on something other than the Oracle VM hypervisor has forced the hands of some users, pushing them to try the Xen-based virtualization offering.”

It’s this sort of FUD (Fear, Uncertainty, Doubt) spreading that’s one of the things I dislike about our industry.  Let me be completely clear ORACLE FULLY SUPPORTS ITS APPLICATIONS VIRTUALIZED ON SOMETHING OTHER THAN ORACLE VM HYPERVISOR.  Don’t believe me?  Check out Metalink My Oracle Support note 249212.1 – Support Position for Oracle Products Running on VMWare Virtualized Environments. Here’s the first paragraph

Oracle has not certified any of its products on VMware virtualized
environments. Oracle Support will assist customers running Oracle products
on VMware in the following manner: Oracle will only provide
support for issues that either are known to occur on the native OS, or
can be demonstrated not to be as a result of running on VMware.

Did you know your Cisco switches aren’t certified by OracleYour DELL servers aren’t certified by Oracle either.

Very very rarely does Oracle certify another vendor’s hardware products.  Certify != support.  Oracle support’s your installation of Oracle productions on VMware just fine.  They take the very reasonable point of view that they’ll help you until they come to believe the issue is VMware at which point they’ll refer you to VMware support.  Seems completely rational to me.

I’ve been an Oracle Apps DBA running Oracle products under VMware for about 4 years.  I have never had Oracle not help me because I run many of my environments under VMware. I’ve spoken with numerous other Oracle DBAs running Oracle products under VMware.  None of us have ever had an issue where Oracle wouldn’t support our environments because we were running under VMware.

I’ll address the rest of the article in another blog post shortly, but seeing this FUD still slung about makes me too annoyed to write coherently.

5 thoughts on “Oracle Support on VMware – your Cisco switches and DELL servers aren’t certified with Oracle

  1. Hi, good article. Oracle have updated their support note recently (nov 2010) to make the wording a bit clearer and include support for RAC from 11.2.0.2 onwards.

    I’m not sure I fully agree with your statement “They take the very reasonable point of view that they’ll help you until they come to believe the issue is VMware at which point they’ll refer you to VMware support. Seems completely rational to me.”

    I’ve read note 249212.1 on the oracle support site and that’s not how it reads to me. What it says is:

    “If the problem is determined not to be a known Oracle issue, we will refer
    the customer to VMware for support. When the customer can demonstrate
    that the issue occurs when running on the native OS, Oracle will resume
    support, including logging a bug with Oracle Development for investigation
    if required. ”

    To me that says if you hit a new bug (i.e not a known ORACLE issue) then you will be referred to VMware for support. Nothing about whether the issue is VMware’s problem or not – the criteria for referral to VMware is “not a known ORACLE issue”. ORACLE will not take it further until “the customer can demonstrate that the issue occurs when running on the native os”. i.e you have to reproduce the problem on physical hardware.

    I would be interested to hear if you (or anyone) has put in a service call to ORACLE support for what turned out a completely new ORACLE bug (i.e had to go back to ORACLE development to write a patch) on VMware and were not first asked to reproduce it on physical hardware.

  2. Funny you ask that… yes, I have put in service calls to Oracle Support for what has turned out to be a completely new Oracle bug (i.e. had to go back to Oracle development to write a patch) on an Oracle system virtualized under VMware and I was *not* asked at any point to reproduce my issue on physical hardware.

    A few examples on various Oracle products that come to mind over the years.

    June / July 2008 – Upgraded from a physical RHEL 4 / Oracle 9i server to VMware virtualized RHEL 5 / Oracle 11g running a database instance for Oracle E-Business Suite. Due to increased memory demands of Oracle 11g vs Oracle 9i and this system running on a 32-bit kernel, the system started running into memory starvation issues. A one-off patch was eventually released. At one point Oracle suggested I talk to RedHat (not VMware) but never was a V2P (virtual to physical) required. This was at times during the life of the SR classified by Oracle as a Sev 1 issue. This was note a VMware bug but a hugemem vs PAE kernel issue.

    Jan 2010 – Upgraded an Oracle EBS system to latest ATG Rollup. Upon turning on the concurrent managers after upgrade, they would consume all available CPU and eventually run out of RAM on App node due to a bug with how scheduled and pending concurrent requests were handled. A Sev 1 issue was opened with Oracle and I although I came up with a workaround to allow the system to proceed normally, a patch was eventually issued. This bug turned out to be multiple *nix platforms.

    Nov 2010 – Oracle GRC product. At time of the issue, Oracle Support in the GRC product group stated they didn’t certify OR support this product being virtualized under VMware or even Oracle VM (yes, I know this is contradictory to official Oracle policy and eventually an Oracle VP needed to step in – blog post coming). Oracle at one point claimed my issue was that the GRC product was failing on syncing with an Oracle EBS system because the Oracle EBS system was virtualized. This eventually became an escalated Sev 2 with Oracle Support and Oracle development and a patch was released. The root issue was missing data in a table in the GRC product and not virtualization. At no point was I asked to reproduce the issue on physical hardware.

    I’m not trying to split hairs on what I’m saying – I run a large number of Oracle products virtualized under VMware and have yet to have Oracle refer me to VMware support and not work on my SR because the system was virtualized.

Leave a Reply

Your email address will not be published. Required fields are marked *