Blog Post

Data Architecture Blog

3 MIN READ

Constrained vCPU and Oracle Licensing in Azure

Microsoft

Dec 17, 2021

Numerous times I’ve experienced misunderstanding on licensing around constrained vCPU VMs. Sometimes the confusion is on the term, “constrained”, (I would have named this VM type, “Same CPU, bigger chassis”.) We’ll go over how we can confirm how many vCPU is on the VM, including comparing a standard VM with 16 vCPU and a constrained 8-vCPU with the 16-vCPU chassis, demonstrating the vCPU count validation between both of them.

We’ll also discuss the continual confusion around the terms of hyperthreading and multithreading. Oracle recently updated their documentation around third party cloud support and licensing, replacing hyperthreading to go to the more generic term for any CPU that can produce multiple threads per CPU.

The third topic stems around the need to distinguish between enabled and disabled in the licensing documentation. Microsoft Support can disable hyperthreading, (or multithreading) on our vCPUs, which some customers choose to do to save on licensing at the cost of performance and paying more on monthly infrastructure. This again, is not to be confused with constrained VM series, as it only covers the vCPU available and that can be counted on the VM.

The following statement from Oracle licensing has nothing to do with constrained vCPUs and everything to do with hyper, now referred to as multithreading vCPUs:

"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."

If there is a question about the validity of the core counts for licensing for any customer, that’s easy to resolve- Ask for an audit! Oracle is going to use the correct procedure to audit and count the vCPUs, just as I will demonstrate below.

Oracle licensing is based off the CPU or vCPU count that is available to the host. Below I have chosen the most common ways you can gather Core/CPU count from a Linux host. Oracle pulls the data from the host, and I’ve used these commands to demonstrate that although poorly named, constrained vCPU VMs have a bigger chassis, but only the number of vCPU that are listed and those are the ONLY vCPUs that Oracle can charge licensing on.

One or more of these commands would most likely be used by any audit team. To prove the results, I just built two Oracle VMs, using Oracle Linux in my own subscription, one with 16-vCPU and then it’s same chassis, but with a constrained, 8-vCPU VM sku.

What do the numbers show?

E16ds v4 16-vCPU

Command	Total CPU	LSCPU INFO
1. lscpu command	16	CPU(s): 16
2. cat /proc/cpuinfo \| grep processor \| wc -l	16	On-line CPU(s) list: 0-15
3. top or htop with "1" option	16	Thread(s) per core: 2
4. nproc	16	Core(s) per socket: 8
5. hwinfo command**	16	Socket(s): 1
6. dmidecode -t processor \| grep "Status: Populated, Enabled" > cpu.lst	16
7. getconf _NPROCESSORS_ONLN	16
8. grep -c processor /proc/cpuinfo	16

E16-8ds v4 8-vCPU Constrained

Command	Total CPU	LSCPU INFO
1. lscpu command	8	CPU(s): 8
2. cat /proc/cpuinfo \| grep processor \| wc -l	8	On-line CPU(s) list: 0-7
3. top or htop with "1" option	8	Thread(s) per core: 2
4. nproc	8	Core(s) per socket: 4
5. hwinfo command**	8	Socket(s): 1
6. dmidecode -t processor \| grep "Status: Populated, Enabled" > cpu.lst	8
7. getconf _NPROCESSORS_ONLN	8
8. grep -c processor /proc/cpuinfo	8

**Had to install outside of the yum repo and install both epel_release and hwinfo, so unavailable normally.

As you can clearly see, the E16ds v4 has 16-vCPU, (8 cores with hyperthreading to total 16) to be licensed by Oracle. The E16-8ds v4 shows 8-vCPU, (4 cores with hyperthreading to total 😎 allowed to be licensed by Oracle. If for some reason, someone was to attempt to license vCPU that can’t be counted with any tool, legal would have a party with them. It’s essential, when having this type of conversation, where either the customer or the salesperson is making Oracle sound more restricting with its licensing than it really is. To combat this, it’s important to deeply understand what terms are being used in the documentation, (it’s not always easy to translate.)

Hopefully this is helpful and happy holidays!

Published Dec 17, 2021

Version 1.0

data architecture

DBAKevlar

Microsoft

Joined January 21, 2020

View Profile

Data Architecture Blog

Follow this blog board to get notified when there's new activity

4 Comments

Kevin_Crouch
Brass Contributor
Apr 09, 2024
I think I'm a bit lost here. The comments, and possibly the post, seem to be focusing on Constrained CPUs being the problem, and a sense that if you are on a constrained 8-vCPU out of possible 16 vCPU, you only need to be licensing 8 vCPUs that are available to your instance.
This part makes perfect sense to me, what is available to your instance.

What I am NOT quite certain of is the indication of how many Oracle licenses these SHOULD properly be licensed with. With some searching, I could not find anything that definitively said (other than this non-authoritative blogpost) [In Azure, each CORE is shown to the processors as TWO HyperThreaded Processors], and I'm not sure if that would hold true for all SKUs, or even all Oracle SKUs.

So, I don't know if the correct play here is to say
- "LSCPU listed it as 4 cores x 2 thread" = 4 cores = 4 Processor Licenses OR
- "LSCPU listed it as 4 cores x 2 thread" = 8 vCPU = (8/2 vCPUs per Processor License) = 4 Processor Licenses OR
- (I think this is where this article was aimed at educating mistaken people) "I selected an Azure SKU with 8vCPU cores (Perhaps, E16-8ds ), and that has 8 'Virtual' processors", and then thinking that Virtual Processor = Virtual Core, that should be *8* Processor Cores.

I see two key parts mentioned.
"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."
and then down lower
E16ds v4 has 16-vCPU, (8 cores with hyperthreading to total 16) to be licensed by Oracle.
The E16-8ds v4 shows 8-vCPU, (4 cores with hyperthreading to total 😎
So, just to make sure I have understood.
In Azure: E16ds v4 has 16-vCPU
Since that ends up being 8 cores with HyperThreading (16 vCPU total), this would be properly licensed as 8 Oracle Processor Licenses?
Slightly differently put: In Azure, you have 16 vCPU, and the guidance said "...count TWO vCPUs as ONE Oracle Processor License [when multi-threading]", so - (16vCPU / 2 vCPU per ProcessorLicense) = 8 Oracle Processor licenses

And for the constrained example
E16-8ds v4 shows 8 (available!)-vCPU, but that is going to show as (4 Cores*2 Threads) = 8 vCPU = 4 Oracle Processor Licenses

And if someone WANTED to make a clearer case, and you had Azure Support manually turn off Multi-Threading, then
(in an admittedly LARGER example VM, that I'm not sure would be actually possible, but to keep from mixing up the examples)
E16ds v4 (With Multi-Threading DISABLED) shows 16 vCPU, as (16 Cores*1 Threads) = 16 vCPU = (16 / 1 Processor Licenses w/o MultiThreading per 1 Core) = 16 Oracle Processor Licenses
TimGormanTech
Microsoft
Jun 10, 2022
xpabu,

You bring up an important point, because Oracle sales frequently attempt to increase revenue in this fashion, by questioning how constrained VMs work.

In the cited paragraph, words matter. The relevant sentence reads...

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...

Please note the highlighted word available? By any definition, available means able to be used. As Kellyn pointed out previously, additional vCPUs allocated to a constrained VM are not able to be used, and therefore are not available. Allocated and available are not the same thing, and that should be the end of discussion.

However, it should be expected for Oracle to attempt additional word contortions, but the base concept enabled versus disabled CPUs is one that Oracle simply cannot fight successfully, when informed people of good intent are involved.

So, an important word of advice: do not engage in lengthy argument with the sales teams at Oracle, as they have an obvious personal vested interest in the count of CPU cores. Instead, demand to be connected with Oracle's License Management Services (LMS) team, which is the team responsible to regulatory agencies for the proper licensing of customers, and work directly with them. Requesting involvement by Oracle LMS is a signal to the sales teams that their game is over. They do not want customers talking directly with LMS. This is why there is a Contact LMS button right on the LMS home page.
DBAKevlar
Microsoft
Dec 27, 2021
Happy Holidays, xpabu- I believe you may have missed the goal of the blog post, which was to explain how the team I work with doesn't have a problem with folks trying to license for CPU that simply don't exist on a constrained vCPU VM. Oracle sales is going to push and challenge due to a misunderstanding of what constrained vCPU machines are. I've just given you the commands required to push back on this challenge. I've had customers try to license by doing thread counts per chip. I've had folks try to multiply each core license by four because they didn't understand the third-party licensing documentation. I'm asking you to reread the blog post and realize that I've given you the means to push back when someone misunderstands.

Legally, no company can come back and say, "I'm charging you for 16 cores when you have 8 on the box because I *feel* like it. " They must have proof there are cores that the customer has access to and could enable, which falls to their technical specialists. The blog post demonstrates that there aren't any cores for Oracle to charge for, just misunderstandings by individuals who don't know what they're doing.

Don't go into a battle unarmed.

Have a great holiday!

Kellyn
xpabu
Copper Contributor
Dec 21, 2021
Hi DBAKevlar ; excellent blog. I agree with all technical aspects of it, however I should raise what I've seen Oracle do in audits -- they have a particular aversion to constrained CPUs in either Azure or AWS and try and base their assessments on the original instance CPU size rather than the constrained number of vCPU. We have seen this in many cases during audit and also at less formal times, the assertion always being "you must license based on the 'original' vCPU count of the instance irrespective. Your E16ds should be licensed on the basis of 8 cores in their eyes.

This has recently been 'strengthened' with the 1 December 2021 updates, specifically: "customers are required to count the maximum available vCPUs of an instance type". Such a statement is still far from 'rock solid', but you could say that about the whole non-contractual document. Any assertion on the basis of maximum vCPUs is non-sensical, based on your analysis above: why on earth would anyone license cores which are not presented in any way to your instance?! There's no business benefit to the licensee for paying license for unusable cores (this extends into other 'unrecognised' configurations such as BIOS-disabled cores)!

There are different ways to approach this, not limited to the below:
ignore the 'clarified' maximum language; use an older version of the ACE document
don't release instance type to Oracle during a review, you almost certainly have no contractual obligation to do so. Simply tell Oracle 'it's 8 vCPUs with HT on'. They won't like this but it is a valid approach.
disregard the whole document as it is non-contractual, base license count on contract only. Oracle will like this less but you will get to use your core factor and you will actually be better contractually-aligned; the use of the core factor table is contractually defined
Each has its own considerations based on 'risk' profile and appetite for an argument. What it is fair to say is that you shouldn't always assume "Oracle is going to use the correct procedure to audit" --we've seen many instances of this not being correct.