Several sources on the Internet report that Oracle states the following in license usage audits:
when using VMware VSphere from version 5.1, all CPUs in all ESXi hosts in all clusters – which are managed by the same vCenter Server and/or use the same physical storage – must be licensed for Oracle.
For example, on the German Oracle User Group, such a message appeared. See: http://www.doag.org/home/aktuelle-news/article/oracle-aendert-lizenzierung-von-oracle-produkten-unter-vmware-vsphere-ab-version-51.html And also on the following community: https://community.oracle.com/thread/3768425?start=0&tstart=0
A clear summary of the situation can be found at the following location: http://blog.dbi-services.com/all-you-need-to-know-about-oracle-database-licensing-with-vmware/
The terms and conditions agreed with you for the use of purchased Oracle licenses are generally set out in the so-called OLSA (“Oracle License and Service Agreement”) or OMA (“Oracle Master Agreement”).
Application of Oracle licenses is often measured by the number of processors used for the Oracle software. The contract defines which processors must then be licensed for Oracle:
‘ Processor: shall be defined as all processors where the Oracle Programs are installed and/or running.’
In other words, all processors on which the Oracle software is installed and/or runs must be licensed.
Unfortunately, this definition leaves room for different interpretations.
Many Oracle users have defined a separate cluster for the Oracle software. The purpose of this is, among other things, to limit the Oracle license costs. We as an Oracle partner have also advised such an architecture in the past. During Oracle audits, the rules were also explained in such a way that only the processors of the Oracle cluster must be licensed.
According to the aforementioned sources, Oracle interprets the rules differently from VMware vSphere 5.1. Oracle has not announced it to our knowledge (in any case, we have not received any announcement, to our knowledge no customers of ours or other Oracle users or partners have received it, and we do not have any online publication from Oracle about this).
As a result, we advise all our customers to have Oracle confirm which servers (virtual and physical) need to be licensed in their specific situation and architecture before building a new environment. Ideally, such confirmation would occur as early as possible in the design phase of newly planned configurations; before actually purchasing licenses. But it can also be useful at a later stage to obtain a ruling from Oracle regarding licenses owed. This could adjust a possible design and make it cheaper.
Here’s an example of how we believe Oracle now interprets licenses. The architecture shown here is widely used when applying VMware in combination with Oracle. (if you click on the preview it will be displayed large)
The red cluster consists of two physical servers running Oracle software.
Oracle’s interpretation in this example is that the Oracle software is installed on all processors of all physical servers shown in the picture.
So also on the processors of the (blue) non-Oracle cluster. Everything within the red dotted lines, according to this interpretation, falls within what needs to be licensed for Oracle.
Perhaps the rationale behind this new interpretation of Oracle is that vSphere version 5.1 offers the ability to move VMs between clusters.
Oracle’s interpretation is therefore that the Oracle software in this example is also installed and/or running on the VMs of the blue cluster.
Many publications on the Internet question this interpretation. To our knowledge, there is no formal/legal statement on this.
If you currently have a VMware vSphere environment with a version from 5.1 and only a part of the processors licensed for Oracle, you run the risk of being addressed by Oracle about this in the future.
Depending on your specific situation, there are various options for avoiding this risk.
An obvious option is, for example, not to virtualize the Oracle environment, but to apply, for example, an ODA (Oracle Database Appliance).
Another possibility is to use Oracle VM (Oracle Virtual Machine) instead of VMware. And, for example, to realize an architecture like the one below. Or, as a variant of this, you cannot replace VMware with OVM for all virtual machines, but only for the virtual machines on which the Oracle software is installed.
Yet another possibility is, for example, to set up a separate vCenter for the Oracle environment, and also to apply separate physical storage (for example, the local storage of the relevant server(s)). Such (strictly separated) architecture is shown below. As far as we know, Oracle does not accept in principle that storage is separated by means of dedicated LUNs or Vplex techniques. So it wouldn’t be enough to set up a separate vCenter configuration where disks come from the same SAN as that of unlicensed servers. However, in many situations this is quite an expensive and invasive operation.
If you want to (continue to) use Oracle in combination with VMWare, we advise you to have the specific desired configuration approved by Oracle. In that case, you do not use a strictly separated environment from the point of view of manageability and costs, and you submit the architecture – preferably in advance – to Oracle. For example, some of our customers have successfully requested explicit permission from Oracle to license only the Oracle servers in storage separation through dedicated LUNs.
We would be happy to provide you with advice tailored to your specific situation.
You can reach our account managers and licensing experts via our contact page .
DBA.nl is the all-round database expert specialized in setting up, maintaining and monitoring database environments. In addition, we provide advice and remove performance problems.
Since last June, we have switched to a working method based on customer teams within DBA.nl....
DBA.nl has launched a new service management system. The choice fell on Topdesk....
DBA.nl, the database experts, may continue to manage the database environment of RID de Liemers....