Oracle Licensing: Soft Partitioning on VMware is Your Contractual Right

Dave Welch (@OraVBCA), CTO and Chief Evangelist

Oracle Corporation’s Tom Kyte did a keynote at Oracle Open World 2006 in a very large hall at the Hilton Union Square titled, “Things you think you know.” I thoroughly enjoyed the session. Quoting from one of Tom’s slides: “It ain’t so much the things we don’t know that get us into trouble. It’s the things you know that just ain’t so …”

Probably 98% of us are willing to admit we’ve been there on substantive issues. The other 2% are liars.

The Oracle Partitioning Policy document has existed in various forms beginning around 2002. Regardless of its various names, its first instantiation defined the difference between Hard Partitioning and Soft Partitioning. The current document’s first sentence makes it clear partitioning has to do with a single physical server. The document’s first instantiation identified VMware as being soft partitioning. As such, the document has always maintained VMware could not be used to limit the number of cores to be licensed within a physical server.

It turns out the Oracle Partitioning Policy document is non-contractual. It is not referenced by the contract (older OLSAs from 2002 through 2012 or the newer OMA 2013-2014), whether by document name, direct URL reference, or even the document’s presence on a generic URL landing page that may be specified by the contract. (In all the Oracle paper we’ve reviewed, we only recall seeing this one contract that actually contains Soft Partitioning and Hard Partitioning definition paragraphs: Pinellas County’s January 2010 ULA draft.) Therefore, quoting the Entire Agreement clause out of the City of Oceanside 2011 OLSA for example, “… this Agreement supersedes all prior or contemporaneous agreements or representations, written or oral, regarding such Programs and/or Services.”

Oracle, at one of our customers, recently had to point out to us the non-contractual status of the Oracle Partitioning Policy document. Before September 2012, the Partitioning Policy document stated all enabled cores must be licensed. The document was versioned in September 2012 to state all cores enabled when the server ships must be licensed. We were asking Oracle to back off the language to pre-September 2012. Oracle declined on the grounds that it couldn’t negotiate terms in a non-contractual document.

I’d been telling people for a decade this doc was contractual based on my belief that I’d seen the contract’s integration of the document. As such, I’d told people I fully expected a judge to vacate the doc’s “for educational purposes only—may not be incorporated into any contract” footer if push came to shove.

Having received this guidance from Oracle, I validated Oracle’s assertion in versions of the Oracle contract minimally through public sources beginning around 2002 when the Oracle Partitioning Policy document was introduced. What Oracle had told us in the negotiation was indeed correct. I was wrong and had missed it on this issue.

Where does this leave us in terms of each of the seven potentially germane Oracle licensing policy documents?


It would appear Oracle had made this all too easy for all of us over the years. Have a look at the footers of each of these seven documents. The five that are non-contractual have the footer stating the document is for educational purposes only and cannot be integrated into any contract or agreement. The two that are contractual have no such disclaimer.

So, let’s have a look at the contract. Scan it and the two policy documents integrated into it by direct reference (those being the Technical Support Policies document and the Core Processor Factor Table) for either of the words VMware or Partition.

  • “Partition” is found but only referring to the Database Partitioning Option, which of course refers to partitioning tables within a database
  • “VMware” is not found


Where does that leave us? Only with the Licensing Definition and Rules subsection “Processor”, which basically says you must license all processors where the Oracle executables are either installed and/or running. That’s it.

With respect to database, the contract is not cluster-based. (Exceptions: the Oracle Standard Edition RAC bundle introduced with 10g, stating the maximum capacity of the physical cluster can be no more than four sockets, and the “enhancement” of the so-called 10-Day Rule in recent years such that the no-cost fail-over node must share a storage array and cluster with the protected licensed nodes.) The contract is not even physical server-based. It’s processor based. Indeed, the contract is agnostic to VMware in every way, whether it has to do with sub-cluster licensing privileges, or sub-server processor licensing.

This is an appropriate time to shout out to License Consulting’s Daniel Hesselink. With respect to the non-contractual status of the Oracle Partitioning Policy document, Daniel had the issue right in his VMworld 2012 session BCA1751 “Virtualizing Oracle to Save on Licensing Costs.”

Join Daniel in person, and me by phone connection, for VMworld EMEA 2014’s Oracle on VMware licensing group discussion (VAPP 3468-GD) moderated by Don Sullivan on Thursday, October 16, 2014 at 1:15 PM.

That said, House of Brick is not ready at this time to endorse that licensees attempt to license less than all CPU’s on a server with any method other than BIOS socket disabling of processors. The reason is that House of Brick currently has no tooling with which we can validate how carefully vSphere respects Core Affinity assignments during normal operations. For example, if a two-vCPU workload is assigned to cores 2 and 3 on a 16-core box, during VM start-up could some of the application code run momentarily on some core other than 2 or 3? Accordingly, House of Brick invites VMware engineering to comment on this issue.

Here is the single test we have run for this issue. We attempted to configure Core Affinity through the Virtual Center Server client on a two CPU sever and assign the VM to non-existent core 3. The user interface rejected that as core 3 didn’t exist. Therefore we edited the .vmx file to assign the VM to core 3. The purpose was to simulate a VM that had been assigned to a disabled or non-existent core, or to simulate vMotion to a server that did not have the same core available as the source server. When we started the VM, it started without regard to the core affinity assignment. The log file shows the VM came up on CPU 0 with no warnings or messages.

On a related note, House of Brick would think it would be perfectly defendable for Oracle to look the other way should its own OVM not be exact in respecting core pinning boundaries should they be configured (we don’t know that), but have every right to legally go after another vendor’s hypervisor technology that may also not tightly respect core affinity boundaries.

So I’m walking this back. I’ve consistently asserted the Oracle Partitioning Policy document was contractual. I can think of these examples:


Of course I’m not alone in having assisted Oracle in promoting the error. It may be that some others have been following my lead.

VMware Corp published a white paper in November 2011 titled “Understanding Oracle Certification, Support, and Licensing for VMware Environments.” The paper included disabling of a socket via BIOS. I wonder if that inclusion led to Oracle’s September 2012 versioning of its partitioning policy document mentioned earlier.

As sorry as I am that I missed this issue, the discovery that the Oracle Partitioning Policy document is non-contractual increases Oracle licensees’ privileges. Ultimately the blame rests with Oracle Corporation for not having eliminated the confusion.

Next blog post: Strategies for Managing Oracle Licensing Compliance in a Shared Storage Environment

1 – Recent versions of the Software Investment Guide (including the March 25, 2014 revision available at at the time of this writing) have introduced this paragraph with some language found nowhere in the contract: “When deploying on shared storage devices, standard-licensing policies applies (sic). All processors where the Oracle programs are installed and/or running need to be licensed.” The convenient proximity of those two sentences in the same paragraph could imply full-cluster licensing even if that is not explicitly stated. House of Brick will deal with this issue in a follow-up blog entry.

Table of Contents

Related Posts