Virtualisation saves money until Oracle disagrees about what you have licensed. The distinction between hard and soft partitioning is where that argument is won or lost, and it turns on data most organisations do not collect.
Originally published May 2016, revised December 2019, and revised again on migration in July 2026.
Virtualisation is a good way to cut infrastructure cost. It is also, where Oracle is concerned, a good way to acquire a licensing liability considerably larger than the saving that motivated it.
The reason is that Oracle has a very specific view of what counts as a boundary. Most virtualisation technologies do not meet it. If you consolidate Oracle workloads onto shared infrastructure without first understanding which side of that line your platform falls on, you can end up owing licences for hardware Oracle Database has never run on.
Oracle divides partitioning technologies into two categories, and only one of them limits what you have to license.
Soft partitioning divides a machine using operating system resource managers, hypervisor CPU affinity settings and similar mechanisms. Oracle’s Partitioning Policy is unambiguous about how it treats these:
…soft partitioning…is not permitted as a means to determine or limit the number of software licenses required for any given server or cluster of servers.
In practice, that means the fact you have pinned a VM to four vCPUs does not reduce your licensable processor count to four. The pinning is, in Oracle’s view, a convenience you have configured and can unconfigure.
The consequence for shared clusters is the one that hurts. Oracle’s audit position on VMware and comparable hypervisors is that if an Oracle workload can run on a host, that host is licensable — so a single Oracle VM in a cluster puts the whole cluster in scope, not just the physical server the VM happens to be sitting on this afternoon.
Be aware that Oracle has not held that boundary still. In audits it has at times argued for a scope wider than the cluster, on the basis that live migration and shared storage make it technically possible for the VM to have run on hosts outside it. Where the line falls in your case depends on your hypervisor version, your storage topology and how the argument is conducted. Treat the cluster as the floor of your exposure, not the ceiling.
Hard partitioning physically separates a server into distinct smaller systems that behave as independent, self-contained machines. Where a technology qualifies, you license the partition rather than the whole box.
Oracle names the technologies it accepts. As at the last substantive revision of this post, the approved list ran:
Oracle VM Server can also be used, but the conditions attached are precise and should be worked through in detail before you commit to a design. Linux KVM was added in October 2019 and requires that you follow a specific process through Oracle Linux Virtualization Manager in order to meet the hard-partitioning requirements.
Two warnings about that list. First, notice how often “capped” appears. An uncapped partition on an approved technology is not hard partitioned. The technology alone does not qualify you; the configuration does.
Second, and more important: this list lives in a policy document that Oracle revises on its own timetable, and the document itself states that it is for educational purposes only and is not part of your licence agreement. Do not treat any reproduction of it — including this one — as current or contractual. Read the version Oracle publishes today, and read your own ordering documents, which are what you are actually bound by.
The awkward property of this problem is that nothing in your infrastructure warns you about it.
The hypervisor console shows you clusters, hosts and VMs. It is doing its job correctly and it has no opinion about Oracle licensing. The database shows you instances and options. It has no idea what it is running on. Neither system holds the fact that determines your exposure, which is the mapping between the two — which database instances sit on which physical hosts, in which cluster, with what processor models, over what period of time.
Nobody assembles that mapping by hand, because it changes every time a VM migrates. So it does not exist until somebody has to produce it, and the person who usually forces that is Oracle’s audit team. By then the position is historical, and you are reconstructing it from whatever logs survive.
The practical requirement is to hold the virtualisation topology and the Oracle deployment in the same place, continuously, and to apply Oracle’s own rules to the result. That is what CerteroX SAM does for Oracle.
Partitioning is a field, not a judgement call. Every host in the Oracle inventory carries its virtualisation type — the virtual architecture it runs on — and its partitioning status, which records whether Oracle recognises that technology as hard or soft partitioned. You are not inferring this from a spreadsheet of hostnames. It is an attribute of the host, visible in the list.
Licensable processors are calculated separately from physical processors. A host shows both the number and type of processors it actually has and its licensable processor count once the rules have been applied — the core-factor arithmetic, in other words, rather than the raw core count. Those two numbers being different is the entire point, and seeing them side by side is what makes a position reviewable.
Core factors are held per processor model, and confirmed deliberately. Processor types are inventoried with their model, speed and core factor. Factors can be set by hand where inventory cannot determine them, and there is an explicit action to confirm a processor’s details, so a human signs off the factor rather than a default quietly propagating across a hundred hosts. Every processor type also shows how many hosts carry it, so you can see immediately where a wrong factor would do the most damage.
The host-to-VM mapping comes from the platform itself. Connectors read VMware, Hyper-V, Citrix XenServer, Oracle VM, Red Hat oVirt, Nutanix, HP-UX and IBM systems via HMC, and the virtual machines they carry. The Oracle VM connector documentation puts the reason for this plainly: without knowing which virtual machines are running on which physical host, and how long they have been there, ensuring licence compliance is not possible. On the IBM side, logical partitions, micro-partitioning and both active and inactive partition mobility are inventoried — which is exactly the detail that decides whether an LPAR is capped and therefore whether it qualifies.
Licence pools carry the non-standard terms. Real Oracle agreements are full of exceptions, and they are the difference between a defensible position and a wrong one. Pools hold the environment the terms apply to, whether hosting rights are included, the list of countries covered where the rights are geographically limited, and minimum overrides. Rather than adjusting the maths by hand each time you produce a position, the exceptions are modelled once and applied consistently.
The compliance position is computed, with the workings visible. Per product and metric: entitlement from your transaction data, used, available, required, licensed, variance and the overspend implied by the unit cost. Options and packs are tracked with evidence and can be overridden where the evidence is a false positive, cover-down logic handles Enterprise Edition, unlimited agreements are held as uncapped quantity, and E-Business Suite is broken out by application, responsibility and user.
Certero is a verified third-party tool vendor with Oracle License Management Services. In Certero’s own words:
Being a verified 3rd party toolset means that Oracle’s audit team can accept data from Certero for Oracle during an official audit, as an alternative to installing Oracle License Management measurement tools.
That is a conditional, not a guarantee, and it is worth reading precisely: Oracle’s audit team can accept the data, during an official audit. But it changes the shape of the engagement. The alternative is running Oracle’s own scripts against your production systems and handing the output to the people who will interpret it.
Virtualise Oracle carefully. The saving is real and the liability is real, and which one you end up with depends on decisions made at design time by people who are usually not thinking about licensing.
Before you consolidate, know three things about every host that will carry an Oracle workload: whether Oracle recognises its partitioning as hard or soft, what its licensable processor count is once core factors are applied, and which cluster it belongs to. If you cannot answer those today, you do not know your position — you have an estimate, and Oracle will produce a different one.
To see partitioning status, licensable processors and the Oracle compliance position calculated across a populated cluster, book a demo.
Other posts covering the same ground.
Locking an application down at user level does not make you compliant with a per-device licence. In a Citrix or RDS environment, one user with access can cost you a licence for every device in the organisation.
A third-party summary of a vendor can be wrong, and it stays wrong for as long as people read it. The case for checking a vendor's facts at source — and the current, sourced record for Certero.
An audit is won or lost on the quality of your inventory long before the letter arrives. Six ways data goes wrong, and what it takes to have the answer already in hand.
Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.
No gated download at the end of it.