I’ve been covering Oracle licensing and support issues in x86 virtualized environments for quite some time, beginning with the January 2008 report “Virtualization Licensing and Support Lethargy: Curing the Disease That Stalls Virtualization Adoption.” You can also view these earlier blog posts for additional background:
- Oracle and the Big Elephant (August 2008)
- A New Year’s Resolution for Oracle (December 2008)
- Oracle Honors its New Year’s Resolution: Non-Oracle x86 Hypervisors are Now Supported (May 2009)
A few weeks ago one of our clients pointed me to a recently published Oracle support article (Metalink 794016.1 published March 27, 2009), which prompted me to write my previous post. That’s when the fun really began. After my last post on May 6th, Oracle published a completely revised version of the Metalink document on May 8th. The document was referenced by the same document ID (794016.1), but had a completely different title and content.
For context, the March 27th version of the Metalink document was titled “Platform Vendor Virtualization Technologies and Oracle E-Business Suite” while the revised May 8th edition of the document was titled “Hardware Vendor Virtualization Technologies on non x86/x86-64 Architectures and Oracle E-Business Suite.” If you recall, the first iteration of the document described how x86 virtualization technologies were supported with the following statement:
The use of platform vendors’ virtualization technologies (both software and hardware based) to host Oracle E-Business Suite 11i and R12 is covered by Oracle’s policy with regards to 3rd-party products – that is, they are ‘not explicitly certified, but supported’.
The support document listed Microsoft, VMware, and Citrix as examples. In the May 8th edition of the support document, the above statement was revised to:
The use of hardware vendors’ virtualization technologies to host Oracle E-Business Suite 11i and R12 follows the same policy as Oracle’s policy with regards to customizations – that is, they are ‘not explicitly certified, but supported’.
Examples of x86 virtualization hypervisors were replaced by the following statement:
This document provides a statement regarding Oracle E-Business Suite (11i, R12) support of Hardware Vendor Virtualization technologies on non x86/x86-64 systems.
The bottom line – the revised support document went from describing support for x86 hypervisors to ignoring them altogether, with the exception of Oracle’s hypervisor Oracle Virtual Machine (OVM). I was told that the revisions were needed to address confusion, but feedback I received from numerous Burton Group clients made it clear that there was no confusion until the May 8th revision was published.
Since early last week, I have had numerous calls with Oracle on the subjects of both licensing and support, and unfortunately the news isn’t all good. Let’s start with the positive. According to Oracle, VMware’s ESX hypervisor “has been supported since November 2007.” As proof, you can view Oracle Metalink document 249212.1 (note that you’ll need an Oracle support account to view the doc). The document states the following:
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.
If a problem is a known Oracle issue, Oracle support will recommend the appropriate solution on the native OS. If that solution does not work in the VMware virtualized environment, the customer will be referred to VMware for support. When the customer can demonstrate that the Oracle solution does not work when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required.
The statement goes on to say that Oracle RAC is not supported on VMware environments. If you’re looking for additional background on Oracle support for VMware environments, I suggest reading the following other perspectives:
- “What the Oracle / VMware support statement really means…and why” (Jeff Browning)
- “Oracle on VMware – a manifesto…” (Chad Sakac)
- “EMC attacks Oracle on its VMware support policy” (Alessandro Perilli)
Regarding VMware support, here’s the translation – if you call for support and you have a known bug, you’re good to go. If you’ve found a new (previously unknown) bug, you’re first going to have to reproduce the fault on physical hardware before Oracle will help you. Compared to other vendors that support enterprise applications on VMware or x86 virtualization environments, this is one of the most restrictive policies out there. Most enterprise software vendors only require faults to be reproduced on the bare metal if they are directly related to performance that could be attributed to the virtualization layer.
The recent Virtual Iron acquisition further cements the fact that Oracle is serious about virtualization. Microsoft and Citrix both have clear public support statements about virtualization and the hypervisors they support (I’m mentioning these two vendors because they’re both virtualization vendors and enterprise software vendors). Oracle needs to loosen its support restrictions for VMware and all x86 virtualization environments, and needs to broaden its list of supported (but not certified) hypervisors to include Microsoft, Citrix, Novell, and Red Hat.
Finally, as I previously mentioned, the larger problem here is licensing. Oracle is requiring customers who wish to deploy Oracle products on x86 hypervisors to license Oracle software by physical server CPUs. Suppose you had two Oracle Database VMs (each with two virtual CPUs) running on a two-node ESX cluster that uses two four-socket servers. Since it’s possible that you’d have a VM on each node, you’d need to purchase licensing to cover the 8 total sockets. If you ran Oracle’s hypervisor, you could license by virtual CPU, however this is only allowed if you pin the VM to fixed CPU cores by hard coding CPU bindings. You can read more about that here. This does create a slight advantage for OVM over competing products, but by binding a VM to one or more physical CPU cores, you have to give up advanced virtualization functionality such as live migration. If I’m using application-level high availability features, this configuration may not be a big deal and would in turn favor Oracle; however it is far from ideal.
Oracle’s competitors in the database arena allow their products to be licensed by virtual CPU without requiring physical bindings (see Microsoft’s and IBM’s policies), and so should Oracle. Doing so allows VMs to move about the physical infrastructure as required to support IT operations. Binding enterprise software licenses to physical assets is a legacy licensing model, and Oracle is practically alone in their licensing policies.
Oracle’s strategy with regard to licensing is one that I’ve seen before. Oracle is effectively taxing organizations for running Oracle Database in a VM. In most cases, organizations will have to pay increased licensing fees. This policy hurts the customer, and in my opinion is an attempt to stall market adoption while Oracle finishes building out its own x86 virtualization platform.
Oracle, it’s time to classify all x86 hypervisors as “hard partitioning.” Our clients are increasingly deploying enterprise applications on x86 virtualization hypervisors. You’re putting them in a tough position, and many consider the virtual infrastructure the foundation for their cloud architecture. Some clients have told me they are now considering moving forward with DB2 or SQL Server because they are unwilling to pay a penalty to run Oracle on any x86 hypervisor. In the end, our clients shouldn’t have to make that choice. They should have the freedom to run the applications they want on the platform they want. This licensing policy is affecting the bottom line of our clients and could ultimately affect your bottom line too. It shouldn’t have to come to that. Let’s just "right the wrong.” Besides, your “Partitioning” document which describes software licensing for virtual environments was last updated in January 2008. In response to my last blog post, you were able to revise a support statement within two days. How about taking the time to revise a licensing policy that is clearly outdated and places an unnecessary burden on our clients?
#1 by Bridget Botelho - May 19th, 2009 at 09:58
Great post Chris. Thanks for updating us on Oracle’s ever-confusing support policies for virtualization.
I agree, it looks like Oracle is stalling on offering broad x86 hypervisor support because they want to perfect their own virtualization offering and corner Oracle customers into using it.
They seem to get away with sub-par virtualization support and high license fees because their users go along with it; I doubt anyone abandons Oracle databases because they don’t like the company’s virtualization licensing and support policy.
But I do know Oracle users are making noise about these issues and should continue to pressure the company for positive changes.
#2 by Chris - May 19th, 2009 at 11:01
Well stated, Bridget. I agree.
#3 by Ceri Davies - May 19th, 2009 at 14:49
As a workaround for the licensing issue, one can run Solaris as the guest OS with the database in a Container, which does count as a “hard” partition.
#4 by Chris - May 19th, 2009 at 16:07
Hi Ceri – you raise a very good point. I have sent an inquiry to Oracle about this seeking clarification. My concern is that while Solaris Containers with capped-CPU resources count as “hard partitioning,” the underlying server virtualization layer would count as “soft partitioning.” Once Oracle gets back to me, I’ll post an update.
#5 by Mike DiPetrillo - May 24th, 2009 at 03:36
Keep up the good fight, Chris. It took MS a while to start changing their licensing and support and they seem to be doing a good job leading that effort now. Hopefully we’ll see Oracle doing the same and hopefully that will be before I die.
@Bridget – I have seen many customers kicking Oracle out of their accounts because of the support issues. They see VMW and Cisco and EMC all leading them down one direction with cloud computing and Oracle running in the complete opposite direction with their licensing and support and lack of vision. The customers seem to want to follow 3 strategic vendors down the same path as their vision rather than stick to a DB that has alternatives in the marketplace. And these aren’t small customers that Oracle is getting booted out from either. Should be interesting to see how Oracle responds.
#6 by Schorschi - May 25th, 2009 at 22:37
I would take the discussion one step down the path of customer direction… Many of the people I deal with, and discuss this topic, of cloud computing, do not want to invest in expensive solutions, so the migration to KVM for example is on the table, leaving VMware behind, or Oracle left for MySQL, etc. True, these open-source or open-source like solutions will not be as easy to implement or support, but many IT managers and vendor product managers are being told, don’t spend money, so what is to be done? We may be seeing the start of an entire new era in IT, where less feature deep solutions, which cost less, are going to dominate the futrue? If this is true? Then Oracle has a significant issue to deal with now.