Oracle on VMware – adding non-standard terms to your Oracle agreement
Most people are aware that Oracle classifies – in its Partitioning policy – the different virtualization/server partitioning technologies into:
- Soft Partitioning
- Hard Partitioning
- Oracle Trusted Partitions for Oracle Engineered Systems
The most commonly used virtualization technology in the market, VMware, is considered “Soft Partitioning”. This means VMware customers are NOT permitted to limit the number of licenses required based on the number of virtual, rather than physical, cores/CPUs in use for any given server or cluster of servers.
But what is Oracle’s contractual basis for this statement, since the Partitioning policy is “for educational purposes only” and is not part of your license agreement? And how does this work for different VMware vSphere versions (e.g. vSphere 5.0, vSphere 5.1 – 5.5 and vSphere 6.0 or higher)? Are there ways of agreeing non-standard terms should you wish to deploy vSphere 6.0 or higher? This article will provide more clarity on all these questions.
Oracle’s Contractual Basis
During the course of an audit, Oracle’s License Management Services (LMS) department will determine your deployment and use of Oracle programs. If Oracle programs are found to be deployed on VMware, Oracle will point you to the contractually agreed license metric definition for “Processor”:
Processor shall be defined as all processors where the Oracle programs are installed and/or running. Programs licensed on a processor basis may be accessed by your internal users (including agents and contractors) and by your third-party users. The number of required licenses shall be determined by multiplying the total number of cores of the processor by a core processor licensing factor specified on the Oracle Processor Core Factor Table which can be accessed at http://oracle.com/contracts. All cores on all multicore chips for each licensed program are to be aggregated before multiplying by the appropriate core processor licensing factor and all fractions of a number are to be rounded up to the next whole number. When licensing Oracle programs with Standard Edition One or Standard Edition in the product name (with the exception of Java SE Support, Java SE Advanced, and Java SE Suite), a processor is counted equivalent to an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket.
As you can see, the contractually agreed Processor license metric definition refers to the Processor Core Factor Table, which can be found at: http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf. This Processor Core Factor table only states the different physical CPUs that can be part of a (physical) server on which the virtual servers and/or the Oracle programs are installed and/or running. Based upon this Processor definition and the related Processor Core Factor table, Oracle will explain that both parties have contractually agreed that the required number of licenses is based upon the (physical) cores of the servers on which the Oracle programs are “installed and/or running”. The installation of the software itself determines the licensing event, independent of the fact whether the software is actually used (running). This is Oracle’s contractual basis for any licensing dispute around the licensing of Oracle software on VMware. It is Oracle’s position that the Partitioning Policy is only to clarify its licensing rules and as such is for educational purposes only.
Different ways of counting
VMware’s vSphere technology provides different functionalities, depending on the specific version used. Due to the different functionalities offered, different ways of counting the required number of licenses are applicable. Below is a simple overview of the major rules that should be taken into account:
VMware’s vSphere ESXi up to 5.0
In older versions of VMware’s vSphere ESXi, up to 5.0, shared storage is required for the virtual machines running Oracle to move throughout the VMware environment. In these situations, the Oracle software is installed on shared storage and the entire cluster(s) connected to the shared storage have the ability to run Oracle. As a result of this, Oracle requires you to license all the physical cores of the physical ESXi hosts that are part of the cluster that is connected to shared storage within the VMWare environment.
VMware’s vSphere ESXi 5.1 – 6.0
In newer versions of vSphere ESXI, 5.1 and later, shared storage is no longer required to live migrate a running virtual machine. A virtual machine running Oracle can move anywhere within the vCenter Server Instance and shared storage no longer serves as the install point for Oracle.
As a result of this, Oracle requires you to license all the physical cores of all the physical ESXi hosts that are part of the same vCenter Server Instance, including across datacenters within the vCenter Server Instance, since the end user has the ability to move the virtual machine running Oracle software to any server within the vCenter Server Instance.
VMware’s vCenter 6.0 and higher
With vCenter Server 6.0 or higher, a running virtual machine can move across vCenter Server Instances which impacts licensing across the entire environment.
As a result of this, Oracle requires you to license all the physical cores of all the physical ESXi hosts of all the vCenter Server Instance(s) which have hosts with ESXi 5.1 or later hypervisors.
Non-Standard Language
Due to these changing rules for more recent VMware releases, the number of licenses required (as per Oracle’s counting policies as explained above) – and the associated cost – is becoming increasingly high.
As such, a growing number of organsiations are successfully adding specific non-standard language to their Oracle license agreement, e.g. through an amendment on their Oracle Master Agreement (OMA). This allows them to “ring-fence” their Oracle on VMware environment and has become a rather standard process within Oracle. Your Oracle Sales representative is responsible for driving this procedure internally within Oracle and for receiving approval to add non-standard language to your agreement. In order to obtain such approval, you will need to have 3 components which address the isolation of the network and storage layer outside of virtualization software features / functionalities. The following details need to be included to obtain this approval from Oracle:
- Architectural Diagram: You need to create an architectural diagram illustrating the existing configuration and planned configuration. In such a diagram, you are required to explain how the network and/or storage layers isolate the Oracle clusters/servers. In addition, you need to detail any specific technology you may use to achieve this goal (e.g. LUN masking)
- Physical Hosts & Storage Layer: You are required to detail how the physical hosts and storage layer are isolated utilizing technology outside of virtualization control.
- Audit Proof: You need to be able to prove how the environment can be quantified and measured during the course of an audit. This could for example be done in the form of network admin screenshots that demonstrate how the hosts are isolated and storage admin screenshots that demonstrate how storage is restricted to only the Oracle hosts.
Conclusion
Many end users read their contractual terms with “their view of the world”. They would argue with Oracle that the agreement does not say that you cannot count virtual cores or virtual processors to determine the number of licenses. Or they would argue that it does not say that there are different rules of counting depending on the vSphere version used.
Organizations should however keep in mind that Oracle remains the owner of the software and dictates the specific terms and conditions under which THEY allow an end user to make use of THEIR software. In short, if and when Oracle does not specify any specific usage right or different way of counting, it does not mean you are allowed to use the software or count the required number of licenses as per your own interpretation. You should obtain upfront (and in writing) approval to use the software differently or to count the required number of licenses differently.
Related articles:
- Tags: Oracle · server partitioning · virtualization
About Richard Spithoven
Richard Spithoven is one of the managing partners at B-Lay. Richard brings more than thirteen years of relevant license management experience to his role having previously served as regional director of compliance at Oracle.
Richard uses his knowledge of enterprise software vendors (such as Oracle, SAP, IBM and Microsoft) to educate, equip and enable software end users in their challenges regarding proper software license management. Richard holds a master’s degree in IT, from the University of Amsterdam in the Netherlands.
Where does the terminology of ‘physical hosts’ and ‘storage layer’ come from? It’s unrelated to the license agreement, so how could it unilaterally be introduced as if it were a relevant phenomenon?
“Oracle remains the owner of the software and dictates the specific terms and conditions under which THEY allow an end user to make use of THEIR software”:
Well. ORACLE completely FORGOT to include any wording around virtualisation in the contract, unlike Microsoft/IBM who exactly stipulate how it works and what restrictions apply, and the client sign off on it upon contracting. There’s nothing wrong with the absence of any wording around using Oracle software virtualized that by the way: The contractual Processor definition can be applied to any virtual environment, full stop. To be able to enforce the Oracle policy document, Oracle should have a definition such as “The number of Processors that can view or have access to any storage where any Oracle Binaries are installed and/or could have access to the Oracle Binaries by means of software re-configuration”. I don’t think that’s what you can make off the actual contractual definitions in place. Unless you’re illiterate.
This is the reality of things: https://blogs.vmware.com/vsphere/2015/04/oracle-licensing-discussion-definitive-collateral-collection.html
So:
1. To voluntarily restrict yourself with any non-standard language is not required.
2. When you do sign it, it often comes at a ‘premium’ cost. It’s being sold as if you get a ‘special’ treatment when it’s a restriction in all aspects with no contractual benefit. Period.
3. Should then you ever change your infrastructure to anything outside the Architecture Diagram (which you will want to do at some point!!!), Oracle will again try to rip you off. Or only sign off a new ‘architecture diagram’ at yet another premium.
4. You can be audit proof, beyond reasonable doubt. There are many ways to ensure and proof contractual compliance, some mentioned here: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/solutions/oracle/understanding_oracle_certification_support_licensing_vmware_environments-white-paper.pdf
“VMware’s vCenter 6.0 and higher
With vCenter Server 6.0 or higher, a running virtual machine can move across vCenter Server Instances which impacts licensing across the entire environment.
As a result of this, Oracle requires you to license all the physical cores of all the physical ESXi hosts of all the vCenter Server Instance(s) which have hosts with ESXi 5.1 or later hypervisors.”
Oracle says that because of Vmotion, you have to license everything without considering the edition of the Vsphere.
1) “The cross vCenter Server and long distance vMotion features require an Enterprise Plus license”.
if you have 2 Vcenters with Vsphere Standard Edition, you only have to licenses 1 and you are in line with your contract (Oracle will say the opposite)
2) “The source and destination vCenter Server instances and ESXi hosts must be running version 6.0 or later”
If your Vcenter Oracle is 6+ and another Vcenter V6 non oracle manage ESXI only 5.1/5.5, your vm may not move to that non Oracle Vcenter. you are in line with your contract (Oracle will say the opposite)
Oracle should investigate deeply on feature Cross Vmotion when they claim licenses.
source : https://kb.vmware.com/s/article/2106952