Once upon a time, VMware and Oracle were great business partners. VMware probably spent a great amount of resources in fine tuning its hypervisor for a smooth execution of Oracle products, and it certainly spent a huge effort in educating the customers about the viability of such virtualized solution.
In mid 2006 Oracle publicly declared its frustration for the lack of standardization in the virtualization market. It eventually decided to enter the hardware virtualization market itself, and launched the Oracle VM virtual infrastructure just one year later. As the company immediately restricted support to its own hypervisor only, the partnership with VMware ended.
The acquisition of Sun and Virtual Iron virtualization technologies suggested that Oracle would never change its mind about the topic, using restricted support as a tool to gain market share.
Meanwhile, VMware continued, for years, to recommend Oracle products on ESX and Oracle’s competitor SAP has been more than happy to highlight its broad support for market hypervisors.
In May 2009, Oracle surprised the market: it updated its support policy to actually provide best-effort help to customers running its applications on 3rd party hypervisors. It was just a mistake in wording: Oracle only wanted to extend its support to the recently acquired Sun virtualization engine running on SPARC architecture, so the statement was changed just a few hours later to include the “non-x86” clause.
Now, last week something changed again. EMC’s Vice President of VMware Technology Alliance, Chad Sakac, reported about a new change in Oracle’s support policy:
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.
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.
NOTE: Oracle has not certified any of its products on VMware. For Oracle RAC, Oracle will only accept Service Requests as described in this note on Oracle RAC 11.2.0.2 and later releases.
Sakac recognizes this as a minor but significant change. Oracle has taken a very similar position a long time ago. In an interview to Computerworld dated November 26, 2007, reported by virtualization.info two days later, the company provided the following statement via email:
Oracle has not certified any Oracle software on VMware virtualized environments,” the company said in a statement. Thus, “Oracle support will assist customers running Oracle software on VMware in the following manner: Oracle will only provide support for issues that either are known to occur on the native OS without virtualization, or can be demonstrated not to be as a result of running VMware. If a problem is a known Oracle issue, Oracle support will recommend the appropriate solution on the native OS without virtualization. If that solution does not work in the VMware virtualized environment, the customer will be referred to VMware for support.
So while, apparently, the difference is where the bug fix can be tested, the reality is that for customers there’s no actual change.
The real news is that Oracle now includes Real Application Clusters (RAC) in this policy statement.
As Gartner’s Vice President of Research Chris Wolf correctly notes, this change is not enough. Oracle still has to modify its licensing policy to stop charging per physical CPU:
…Most Oracle customers license Oracle products by CPU core. In VMware environments, Oracle has asked customers with core-based licensing to license every physical core in an ESX cluster. The result is that customers often have to pay added licensing fees to run Oracle workloads in VMware VMs. Some clients have had to run Oracle workloads in small ESX clusters to stay within licensing compliance. Many have decided not to virtualize Oracle products until licensing restrictions were eased so that organizations would not have to pay more to run Oracle workloads in x86 VMs…
Wolf also highlights an interesting paradox related to the recent inclusion of Oracle VM in Amazon EC2 :
…An interesting side note in the licensing conversation is that Oracle allows licensing by vCPU for instances deployed to Amazon Web Services. Why make an exception for Amazon and not for VMware, Microsoft, Citrix, and other virtualization vendors?
…
The document “Licensing Oracle Software in the Cloud Computing Environment” describes OVM licenses on Amazon EC2 as follows:
Licensing policy for Oracle VM in EC2 environments: Amazon has implemented Oracle VM EC2 instances in accordance with the practices defined in the Oracle policy document titled, ‘Hard Partitioning with Oracle VM‘, which is referenced in Oracle’s Partitioning Policy. This ensures that a given virtual processor in an EC2 instance is assigned to a specific physical core on the backend server. From an Oracle product licensing point of view, this means that each virtual processor is equivalent to a physical core, and the standard Oracle Processor metric definition applies.
So to summarize, Amazon AWS is getting better licensing terms than Oracle even affords to its own hypervisor…