There have been recent discussions on LinkedIn forums and the like purporting the idea that the new version of vCenter increases the risk/liability of your Oracle licenses. In this post I will explain how VMWare works architecturally, how the Oracle Grant is currently written, and why, despite recent claims to the contrary, you have a defensible position regardless of what vCenter version you are using.

VMWare architecture

Firstly, I wanted to ensure that we are speaking the same language and that our clusters are similarly configured. I’m not a technical architect (though I do play one sometimes), so I’ve had one of my TAs review and bless it.

1 – No vCenter to manage the Instances


Oracle Clusters with no vCenter Management console

Secondly, we will review the baseline license requirements when Oracle VM manually migrates from Cluster 1 to Cluster 2. It will set the baseline consumption of the entitlements and will allow us to explore if and how the license liabilities change in each of the other scenarios.

2 – vCenter 5.1 to Manage the Instances


Oracle Clusters with vCenter 5.1 Management console

We will also review the license requirements when one of the VMs is moved from Cluster 1 to Cluster 2 in an offline transaction using vCenter. This requires the Cluster to share storage or have storage replication set up.

3 – vCenter 6.0 with CrossSite vSwitch/vCenter vMotion


Oracle Clusters with vCenter6 Management console

Lastly, in this scenario we will review the license requirements when one of the VMs is moved from Cluster 1 to Cluster 2 in an online transaction using Cross vSwitch vMotion or Cross vCenter vMotion. This does not require the clusters to have shared storage nor to be controlled by the same vCenter instance; however if moving the VM from one vCenter controlled Cluster to a different cluster controlled by another vCenter both vCenters will need to be vCenter 6 or above.

Oracle License Grant


Oracle License Grant from the OLSA

In these examples we will look at the exact wording of the license grant for a license of Oracle EE. Here is the current license grant:

The important aspect is, “…as all processors where the Oracle program are installed and/or running…” which means that any and all physical servers that the Oracle VM touches are required to have licenses. Here is where it gets tricky and where others have made claims of increased license liability, but let’s take a look at each scenario above. The number of required licenses (under the processor model) is 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. For the sake of simplicity, let’s just assume everyone is using Intel E7 series processors (0.5 factor).

In Scenario 1, we have Cluster 1’s license liability as 24 Oracle DB EE Licenses (48 Cores x 0.5 Oracle License/core). If the virtual farm admin were to do a manual movement of an Oracle VM from Cluster 1 to Cluster 2, they could only do it in an offline mode but would also add 36 Oracle DB EE licenses (72 Cores x 0.5 Oracle Licenses/Core). This means if Oracle VMs existed in both clusters the license liabilities would form a grand total of 60 Oracle DB EE Licenses. However, the risk of your vCenter admin moving VM from one cluster to another is low because why would he/she do that? Clusters are configured for a certain capacity and purpose. Go ask an Enterprise or technical architect to put a Database server in an application cluster; they will resist. Why? Because it makes their job much harder to perform in the long term.

In this scenario you license obligations is 24 Oracle DB EE Licenses unless someone purposely moves a Oracle DB VM into cluster 2. At the time the VM is spun-up you will be obligated for an additional 36 licenses.

In Scenario 2, we have the same license liability as the above scenario but the movement of VMs from one cluster proves to be a bit easier. Again, movement cannot take place while the VM is running, but is fairly simple nonetheless. In this scenario the VMs move around their respective clusters freely (see Bonus for another perspective). Regardless, the licenses’ liability for cluster 1 is 24 Oracle DB EE. If/when you move an Oracle DB EE VM to Cluster, the liability increase another 36 Oracle DB EE licenses forming a grand total of 60 Oracle DB Licenses.  Are you seeing a pattern yet? Let’s explore the next scenario.

It has been argued that the license liability in Scenario 3 is the full capacity of all clusters with vCenter 6. Let’s just revisit the license grant wording to confirm… “…as all processors where the Oracle program are installed and/or running…” Before the migration/move of the Oracle VM, only cluster 1 needs to be licensed. Normally, this would not be configured out of the box and is not a configuration that is “automatically” enabled. The vCenter Admin needs to specifically choose to move the VM from one cluster to another. What this means is, should the vCenter admin move the Oracle VM from Cluster 1 to Cluster, the licenses’ liability is… you guessed it: 60 Oracle DB EE.

So as we’ve seen, in all scenarios, when an Oracle DB EE VM moves into a Non-Oracle Cluster you will be obligated to license that entire cluster. Therefore, having vCenter 6 does not increase the risk or obligations. It does however highlight the need for SAM to collaborate and communicate closely with the IT Operations, Technical architects, and Data Center Managers. It is imperative to share our concerns and ask them to seek advice when configuring their infrastructure. A bit of foresight and education save you some headaches (and financial troubles) in the long term.

Defensible Position

So why are we even talking about this? Well it’s because increasingly publishers (not just Oracle) are using audits as a predatory tactic to drive sales.  Typically organizations don’t know license metrics as well as the publishers. They rely on third parties (like ones provided by Beaconize) to keep the publishers honest pre, during, and post audits. In the case of Oracle on VMWare platforms, it is fairly easy to create a defensible position.

On every vSphere Host, there is a log file which contains the full history of guests who have visited it. These are located at /var/log/vmware/hostd.log and /vmfs/volumes/datastore/vm/vmware.log. These create a chain of evidence which will prove well beyond a reasonable doubt where the VMs have been on each host. Knowing where each VM has been during the audit period, will establish where your license obligations are.

*ProTip: During an Audit, limit the period threshold which they will review in the audit response letter.

Use a 90-day period as it provides enough of a sample size to show how you have been operating. This needs to be done and accepted in the first written interaction.


If you still want to follow the letter of the current license agreement from Oracle, then you can use the VMWare Affinity rules to “pin” VMs to specific Hosts. This can effectively reduce your license obligations. Here is an example:


Bonus: How to reduce your Oracle license obligations in virtual enviroment

In this example you have all the Oracle VMs “pinned” using affinity rules to Hosts 1 and 2 but “barred” from entering Host 3. This would see your Oracle DB EE License liability be 16 (4 CPUs x 8 Cores/CPU x 0.5 Oracle Licenses / Core). This way you can effectively control your Oracle spend without exposing yourself to license liabilities. I will caution you though: although this is 100% allowed according to the current license grant by Oracle, it does not mean that they will not challenge this. To proceed with caution, make sure you have your virtual infrastructure set up correctly and ensure you have a chain of evidence. Just because Oracle does not like customers doing this type of licensing does NOT mean that it is breaches the license agreement.
For more details, please review VMWare’s license position on the matter and/or consult your legal representative.