Hypervisor Choice and Oracle Licensing: Why the Platform Sets the Bill

For most software, the hypervisor is an infrastructure decision. For Oracle it is a licensing decision, because Oracle's partitioning policy decides whether a virtual machine is licensed on the cores it uses or on every core it could ever run on. Under one class of hypervisor a two-vCPU database is two licences; under the other it is the whole cluster. The difference is the single largest lever in most Oracle positions, and it is set by a document that is not part of your contract.

This article explains the policy, the hard and soft partitioning lists as Oracle applies them, what each common platform means for the count, and how to make the platform choice with the licence bill in front of you.

The partitioning policy

Oracle's Partitioning Policy document distinguishes hard partitioning, which Oracle accepts as a way to limit the number of processors that must be licensed, from soft partitioning, which it does not. On a soft-partitioned platform, Oracle's position is that the programs are "installed and/or running" on every processor the VM could be moved to, so every core in the cluster is counted, and with some platforms every core in any cluster sharing the same storage or management domain.

Two facts about that document matter more than its content. It is a policy, not a contract term: your licence agreement says "installed and/or running" and leaves the interpretation to the policy, which Oracle can revise. And it is the interpretation Oracle's auditors apply, so it is the number you will be asked to pay unless you contest it, and contesting it means litigation. A position should therefore be built under the policy and the disagreement, if any, kept for the negotiation.

The platforms and the count

The list is Oracle's and it changes. Check the current Partitioning Policy for the platform and, for Oracle Linux KVM, the specific configuration requirements: the pinning must be done as Oracle documents it, with the tools Oracle names, and it must be auditable after the fact.

What this does to a real cluster

Take a twelve-host vSphere cluster of two-socket, 32-core Xeon servers: 768 physical cores. One Oracle Enterprise Edition VM with four vCPUs runs on it. Under the policy the installation is 768 cores × 0.5 core factor = 384 Processor licences, plus 384 of every option the database uses. The same VM on a dedicated two-host cluster is 64 × 0.5 = 32 licences. On Oracle Linux KVM with four pinned cores it is two. The workload is identical in all three cases.

The reverse also happens. A team that isolates Oracle onto a small cluster and later joins it to a larger one for operational convenience, or enables cross-cluster vMotion, has multiplied the position without installing anything.

The options, in order of cost

1. Dedicated physical servers. No policy argument at all: the count is the servers' cores. Works for a small number of large databases.
2. A dedicated, isolated soft-partitioned cluster. Keep vSphere, but the Oracle cluster shares no hosts and, to be safe against the wider readings of the policy, no vCenter and no storage with non-Oracle clusters. Size it to the workload; every host in it is licensed in full.
3. Hard partitioning on an Oracle-accepted platform. Oracle Linux KVM with pinned vCPUs, configured exactly as documented. The licence count follows the pins. The cost is a second virtualisation platform and the discipline to keep the configuration auditable.
4. Authorised cloud. AWS, Azure or OCI under the cloud policy, where the count is the instance's vCPUs. Removes the cluster argument entirely, at the price of the cloud bill and, for BYOL, the different exchange rate per provider.
5. Stay on the shared cluster and license it. Occasionally right for a very large Oracle estate that already fills the hosts; wrong for everyone else.

Making the decision with the number in front of you

The platform question is answered by pricing each option on the counting rule that applies to it, for the databases you actually run, options included, against the migration cost and the operational cost of the isolation. That requires knowing, for every Oracle VM, the hosts it can reach today, the cores and CPU model of each, and the edition and options in use. Most estates cannot produce that list on demand, which is why most positions are built on the vendor's assumptions rather than the customer's data.

It is the reconciliation Infrastructure Mapper and Oracle Database Manager maintain together: cluster membership and mobility boundaries from the hypervisor, CPU models and cores per host, and the Oracle usage on each VM, priced under the core factor table on the boundary the policy assigns. The output is the cost of the estate as it is, and the cost of each of the five options above, which is the only basis on which a hypervisor decision for Oracle should be taken.

Checklist

• Every Oracle VM mapped to the full set of hosts it can reach, including cross-cluster mobility and shared management domains.
• Platform classification checked against the current Partitioning Policy, configuration requirements included for any hard-partitioned claim.
• Position priced on the policy's boundary, options included, with the disagreement (if any) documented separately.
• Each isolation option priced against the migration and operating cost, on the same database list.
• Change control on cluster membership for Oracle hosts, so the position cannot be multiplied by a convenience change.