Forum Discussion
TimGormanTech
Microsoft
Jul 14, 2022Clarifying false assertions by Oracle sales about Oracle licensing on Azure constrained VMs
Recently, I received the following question from a customer...
How much of a challenge would it be to defend against Oracle's claim that, for a constrained Standard_E96-24ds_v5 VM, we owe them licensing for 96 vCPUs instead of 24 vCPUs?
I've been receiving questions of this sort more frequently these days, so I wanted to share advice on dealing with it.
Oracle's own documentation on public cloud licensing (HERE) states...
For the purposes of licensing Oracle programs in an Authorized Cloud Environment, customers are
required to count the maximum available vCPUs of an instance type as follows:
Microsoft Azure – count two vCPUs as equivalent to one Oracle Processor license if multi-threading of processor cores is enabled, and one vCPU as equivalent to one Oracle Processor license if multi-threading of processor cores is not enabled
Please note that the highlighted word available which means able to be used or obtained; at someone's disposal according to the Oxford dictionary.
Azure constrained VMs are explained HERE, including the following description...
Azure offers certain VM sizes where you can constrain the VM vCPU count to reduce the cost of software licensing, while maintaining the same memory, storage, and I/O bandwidth.
The vCPU count can be constrained to one half or one quarter of the original VM size. These new VM sizes have a suffix that specifies the number of active vCPUs to make them easier for you to identify.
So, constrained VMs in Azure offer only the memory, storage limits, and I/O bandwidth associated with a VM of a larger number of vCPUs in the name, but the number of vCPUs is the lower number in the name.
For example, in the case of the above-mentioned Standard_E96-24ds_v5 VM instance type, the "96" represents the memory, I/O, and network resources normally associated with a 96 vCPU virtual machine, but it does not indicate that 96 vCPUs are available. Only 24 vCPUs are available with this instance type, and that is the count to be used when licensing Oracle.
Referring to the guidance from Oracle licensing provided above, these 24 vCPUs, each hyperthreaded by 2, represent 12 CPU cores, so the number of Oracle processor licenses for this VM is 12.
As an interesting side note, according to the same Oracle documentation on licensing in public clouds (HERE)...
When counting Oracle Processor license requirements in Authorized Cloud Environments, the
Oracle Processor Core Factor Table is not applicable.
Thus, the popular Oracle Processor Core Factor Table discount is available only on-prem and in Oracle cloud, but not in Azure. This is the basis of another myth by Oracle sales teams suggesting that Oracle database is half as expensive in Oracle cloud than in Azure. It has nothing to do with technology or performance or cost of resources, merely a discount that Oracle has reserved only for themselves.
Of course, for basic technical questions such as counting CPUs, there must be an empirical way to prove one way or the other. Oracle is welcome to recommend any Linux or Oracle utility they prefer to count the number of vCPUs presented by a VM, but one good suggestion is the Linux lscpu command. Whatever count is returned by such a utility should determine licensing count, of course.
In summary, please beware of Oracle sales personnel attempting to freelance with their own perspectives on licensing. Oracle sales personnel are not the most reliable source of such information, due to the obvious conflict of interest. Oracle's License Management Services (LMS) team provides authoritative decisions on licensing.
When anyone spreads misinformation about Oracle licensing, then please click the Contact Oracle LMS button on the LMS home page to get the word from the folks who can provide the real answer.
- VirileBrass Contributor
I'm mostly curious as to why they charge by the processor and in what way that makes sense. I guess you've got to choose where to charge somewhere. Was there like a coin flip, or like someone noticed there might be a nifty way to overcharge customers and was like "Yeah, that, let's do that!"
¯\\_(ツ)_/¯
Lots of talk regarding Oracle around here. (Well, meh, this is the second I've run into.)
Sounds like both a resource hog, and that they charge off an interesting choice of hardware (which is likely virtualized in some way anyhow). I'd be interested to know the link between Oracle and charging by the number of cores Asserting though, urgh, incredulous.
HyperV, anyone know if it alleviates strain from Oracle processes?
~ V
Edit: Because I had said Hypervisor and meant HyperV --> https://www.unitrends.com/blog/hyper-v-azure-and-oracle
- TimGormanTech
Microsoft
Virile - lately, I've just taken to summarizing that Oracle trying to charge based on their poorly reasoned misinterpretation of a VM naming convention is the same logic as assuming that butterflies are made of butter.
Sometimes it sticks, sometimes it just slides off.