Oracle posted a blogpost titled “Impressions from VMworld – Clearing up misconceptions” which inclued a short reaction on the licensing discussion that flared up during VMworld 2012:
“In the world of multi-vendor IT stacks, understanding license boundaries and terms and conditions for each product in the stack can be challenging. Oracle’s licensing, though, is straightforward. Oracle software is licensed per physical processor in the server or cluster where the Oracle software is installed and/or running. The use of third party virtualization technologies such as VMware is not allowed as a means to change the way Oracle software is licensed. Exceptions are spelled out in the licensing document labeled Hard Partitioning“. (full article here)
This confirms what was said earlier (link 1, link 2): Oracle software is licensed per physical processor in the server or cluster where the Oracle software is installed and/or running. Unfortunately there’s nothing about the DRS thing in the article…but, as long as you limit the number of ESXi servers on which the Oracle application can run (and you can proove this by the means of an audit trail/log files) you seem to be okay. Again, Oracle is not really interested on how you achieve this: a seperate Oracle cluster, DRS groups or something else.
About the (hard) partitioning thing which is mentioned in the article: “Partitioning” occurs when the CPUs (a.k.a. processors) on a server are separated into individual sections where each section acts as a separate system. Sometimes this is also called “segmenting.” (from this whitepaper, note this offical Oracle whitepaper has no legal value as mentioned in the footnote).
Partitioning is something you can do within one server and has nothing to do with clusters. The case is: you cannot use vSphere CPU pinning/CPU affinity to decrease license costs for a VM running an Oracle application. You always have to license all physical CPU’s of an ESXi host if an Oracle application is running on it.
That’s it, always check with your license vendor if you’ve got things correctly licensed. The purpose of this article is just to inform you about the subject and of course I take no liability.
2 Comments
Gabrie van Zanten
Too bad Oracle doesn’t allow comments on their site, posted a question but never appeared. In their blogpost the author mentions a vSphere Cluster, but there is no mention of a VMware Cluster in the PDF he refers to, only server. The big difference is that according to the PDF you could license a 2 vCPU VM on a 4 CPU host in a 5 host cluster with just 4 licenses (all CPUs on the server). According to the author however you would have to license 20 CPUs which are all the CPUs the VM could run on in the DRS cluster. I am affraid is the last one…..
viktorious
What I understand is: “you [only] have to license all processors where the Oracle programs are installed and/or running on”. So, you only have to license the ESXi servers where your Oracle application/DB is running on. If you have enabled DRS groups which limits the options, you only have to license the selected ESXi servers.
When Oracle performs a license audit, they will check on which CPU’s your application has run on (this is recorded in the software as far as I understood). This determines how much licenses you need/should have. This was told by people that know what they are talking about. Still in doubt? Contact Daniel or otherwise Jan Willem of VMware. At the end it’s the customers choice what to do…
One other thing: Some customers choose to configure a seperate cluster, especially for the Oracle solution/VMs. This can be beneficial, e.g. if you have octa-core in your normal cluster and only need quad core for the Oracle applications (this will reduce license costs). But is this a sufficient boundary if you can still vMotion from one cluster to the other? What is the difference with using DRS groups? Because it’s manual it’s no problem? Well, I can change the DRS automation setting to manual for the Oracle VMs and I’ve created exact the samen configuration. So maybe I have to create a separate vCenter Server for the Oracle servers…that’s one step too far I think :S