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 8) 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!
Posted at https://sl.advdat.com/3svEmJ5