Dave Welch, CTO, Chief Evangelist and David Woodard, COO

About a year ago, some joint customers of Oracle, VMware, and House of Brick began to be informed they needed to purchase Oracle licenses for all nodes sharing storage.

Oracle Contract Basics

Let’s start by looking at what the Oracle License and Services Agreement (the contract) says you have to do. We’ll use the City of Oceanside’s November 2011 OLSA, as it’s publicly available and scanned reliably through our OCR software, for reference (or pull this scannable December 2012 OLSA if you don’t want to bother with OCR). The OLSA says:

Processor: shall be defined as all processors where the Oracle Programs are installed and/or running.

That’s it. There’s the physical scope of your Oracle licensing obligation. We’ve heard Oracle tell customers, “You could run the software on these nodes, therefore you must license them.” Au contraire, there is nothing prospective about the Oracle contract’s licensing obligation.

Full Cluster Licensing Assertion

On our way to a discussion of full shared storage licensing, let’s have a look at full cluster licensing. Is there anything in the contract stating you have to license the entire cluster? Scan for the word “cluster.” You get:

• The cluster restriction for the so-called 10-Day Rule
• The 10g SE RAC bundle’s physical cluster capacity restriction
• WebLogic Server SE doesn’t include WebLogic Server Clustering
• A reference to Real Application Clusters
• A reference to MySQL Clustering

None of what comes back in the “cluster” search has anything to do with full vSphere cluster licensing. Try the same search on the Technical Support Policies and Processor Core Factor Table docs the contract integrates by reference (the latter referenced by later 2008 OLSAs and newer). You’ll find nothing specific to VMware. While you’re at it, search for the words “VMware,” “ESX,” “vSphere,” “virtual,” etc. Should you have the opportunity to examine Oracle’s newer Oracle Master Agreement (OMA) that advented around February 2013, your search will lead you to the same conclusion. (See post Oracle Licensing: Soft Partitioning on VMware is Your Contractual Right regarding the “Entire Agreement” clause.)

So with that exercise, you just validated what Oracle’s former Director of Cloud Business Development EMEA, Richard Garsthagen, said in a VMworld 2012 TV spot (thanks to License Consulting’s Daniel Hesselink for preserving a copy of the video before it disappeared from vmworld.com).

We can’t imagine any motive VMware Corp would have to pull down Oracle-related content short of a request to do so from a corporate neighbor. Our suspicion is VMware is entirely too cooperative of a corporate neighbor. That someone may have felt the need to get the video pulled down takes nothing away from the 100% Oracle contractual compatibility of what Mr. Garsthagen said.

Our on-going interaction with Oracle sales reps causes us to wonder if some of them realize that just as an Oracle Database instance cannot execute on more than one physical server at a time (either single instance or RAC), similarly a VMware virtual machine cannot execute on more than one physical vSphere server at a time. Related to this, the first sentence of the non-contractual Oracle Partitioning Policy guide makes clear that license partitioning is a server-level concept.

All Nodes Sharing Storage Licensing Assertion

So let’s move on to the assertion that all nodes sharing storage need to be licensed for Oracle. We’ve seen this assertion being made into some House of Brick customers and prospects for about a year now. Within days of pre-advertising this blog post, the issue blew up in the German Oracle User Group (DOUG). Here’s a reasonable edit of the output from MS Word’s on-line translation service (better yet, try your own hand at running a translator and interpreting the output, or find someone who speaks German):

“Although the Oracle license contains no statement to this effect, Oracle asserts new licensing regulations for Oracle products on vSphere. As of vSphere version 5.1, you must not only license an entire cluster, but all clusters anywhere in the vCenter in which Oracle software is installed or running.

“As justification for this change, Oracle notes vSphere version 5.1 is capable of moving across clusters within vCenter.

Go back to the OLSA and the policy docs it integrates by reference. Scan for “storage,” “shared storage” or similar wording, and see if you come up with anything affirming such a shared storage licensing obligation.

A VMware administrator not familiar with an organization’s Oracle licensing scheme could move a VM containing Oracle to a non-licensed vSphere node. Despite a DRS Host Affinity “MUST” rule, a VMware administrator could attempt to override the rule. We would agree if the VM actually moved to an unlicensed node, the Oracle software was mounted into the VM, and the breach was then remediated, the customer could have a license and support obligation to Oracle which could be a one year term license including support as Oracle doesn’t sell less than a one year term license.

Managing The Shared Storage Licensing Risk

DBAs may argue that for the Oracle database to be installed would require the existence of any number of artifacts including node-specific oratab, orainst.loc, Oracle Inventory, and admin directories. However, there is a possibility that Oracle Corporation could prevail with an argument that Oracle is installed, as follows:

1. Shared storage containing Oracle software is mounted on a node
2. Either the software is in the PATH or the software is the current directory
3. $ export ORACLE_SID=[SID name]
4. $ sqlplus
5. SQL> startup;

At this point there is an Oracle Database software instance running despite the fact that no more formal installation took place to create the above artifacts.

It is our assumption that Oracle License Management Services (LMS) discovery scripts are looking for at least Oracle inventories and Oracle binaries.

What follows in this paragraph is not needed for contract compliance under normal operations. However, to further protect yourself operationally against human error, consider LUN zoning and/or masking. In other words, control access to the vSphere data store at the fiber/network level. NFS-based arrays normally have the ability to be configured at the array level to restrict access to certain hosts. At a lower level, any Unix/Linux server can control access via the /etc/exports file.

Oracle’s Software Investment Guide (most recent archived copy from 2/19/18) illustrates this licensing segregation via storage volume mounting. See heading “Shared Storage example on Exalogic Elastic Cloud…” on p. 23 (rev 25 March 2014). We don’t see anything in the Tuxedo/WebLogic Suite example that is incompatible with the contract.

The example shows a “Non Virtualized Environment.” But clearly that is an example. The point of this section in the Software Investment Guide is to discuss mounted and not mounted for the purposes of determining if software is “installed.”

The optional VMware VMDK is a storage container that can only be opened by one VM at a time (the exception being setting the multi-writer flag such as is the case with Oracle RAC).

Conclusion: a storage volume containing Oracle software that is inaccessible to a server by whatever mechanism or means obviously prohibits that software from being installed and/or running on that server.

Related Post: Oracle Licensing: Soft Partitioning on VMware is Your Contractual Right