It is rather known in the market that Oracle classifies – in its so called Partitioning policy – the different virtualization or server partitioning policies into “Soft Partitioning”, “Hard Partitioning” or “Oracle Trusted Partitions for Oracle Engineered Systems”. The most common used virtualization technology VMware is considered “Soft Partitioning” and as such considered as a technology which is NOT permitted as a means to determine or limit the number of software licenses required 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 then work for different VMware vSphere versions (e.g. vSphere 5.0, vSphere 5.1 – 5.5 and vSphere 6.0 or higher)? And are there no other ways of agreeing any non-standard terms and conditions if and when you would like 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 department will determine your deployment and use of the Oracle programs. In case the Oracle programs are found to be deployed on VMware, Oracle will point you to the contractually agreed license metric definition 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: https://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: https://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. Its Oracle’s position that its Partitioning Policy is only to clarify its licensing rules and as such 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 a simple overview of the major counting 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, a shared storage is required for an end user to move the virtual machines running Oracle 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, end users no longer need to have a shared storage to live migrate a running virtual machine. The end user can move the virtual machine running Oracle anywhere within the vCenter Server Instance. The shared storage no longer serves as the install point to run the Oracle programs because of the ability to move a virtual machine from one host to another within the vCenter Server Instance using vMotion. As a result of this, Oracle requires you to license all the physical cores of all the physical ESXi hosts that are part of one and 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 the developments at VMware through which it is possible to move virtual machines from one vCenter Server Instance to another vCenter Server Instance, if and when vSphere 6.0 or higher is being used, the number of licenses end users require (as per Oracle’s counting policies as explained above) is getting extremely high and expensive.

As such, more and more end users are successful to agree specific non-standard language with Oracle in their license agreement (e.g. through an amendment on their Oracle Master Agreement (OMA)) through which they are allowed to “ring-fence” their Oracle-VMware environment. This procedure has become a rather standard process within Oracle. Your Oracle Sales representative is responsible for driving this procedure internally within Oracle and to receive 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 approval from Oracle:

Architectural Diagram: You need to create an architectural diagram illustrating the existing configuration and planned configuration. In such diagram, you are required to explain how the network and/or storage layers isolate the Oracle clusters/servers. In addition, you need to detail out any specific technology you may use to achieve this goal (e.g. LUN masking)

Physical Hosts & Storage Layer: You are required to detail out how the physical hosts and storage layer are isolated utilizing technology outside of virtualization control (e.g. by you providing screenshots).

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 at all times 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 therefore, by definition, does not mean that 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.