Oracle on VMware – adding non-standard terms to your Oracle agreement

Oracle

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 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. 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:

1. 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)
2. Physical Hosts & Storage Layer: You are required to detail how the physical hosts and storage layer are isolated utilizing technology outside of virtualization control.
3. 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.

Can’t find what you’re looking for?