Why virtualization matters under a ULA
Virtualization is the single most contested topic in Oracle licensing, and a ULA changes the stakes in two opposite directions. During the term, the unlimited deployment right neutralises the usual virtualization risk, because the customer can run Oracle on any number of hosts without counting. At certification, however, virtualization becomes decisive, because how the customer counts processors across a virtualized estate determines the size of the perpetual entitlement it locks in. Understanding oracle ula virtualization means understanding that the freedom of the term and the rigour of certification are two different problems, a distinction the Oracle ULA pillar guide draws throughout.
The core difficulty is Oracle's partitioning policy, which classifies virtualization technologies as either hard partitioning, which Oracle accepts as limiting the licensable cores, or soft partitioning, which Oracle does not recognise as a boundary. VMware, the most widely deployed platform, is treated by Oracle as soft partitioning, meaning Oracle's position is that every physical core a virtual machine could potentially run on must be counted. This policy drives both audit disputes and certification arithmetic, and it is examined in detail in the database cluster article on soft partitioning.
During the term: virtualize freely
While the ULA is active, the partitioning debate is largely moot for in scope products. Because deployment is unlimited, it does not matter how many cores a VMware cluster exposes or how Oracle would count them, since the customer is not paying per processor during the term. This is one of the genuine operational benefits of a ULA: it removes the constant tension between infrastructure flexibility and licensing cost that plagues virtualized Oracle estates outside a ULA. Teams can consolidate, migrate virtual machines, and scale clusters without licensing friction for the products on the schedule.
A ULA buys three years of freedom from the VMware counting argument. Certification is when the argument comes back, and it comes back permanent.
This freedom is real but temporary, and it carries a trap. Customers who enjoy the term's flexibility without planning for certification can build a sprawling virtualized estate that becomes extremely difficult to count favourably at term end. The discipline is to enjoy the operational freedom while quietly preparing the certification position, so that the estate the customer certifies is structured to count well, a theme that runs through the certification process guide.
How is virtualization counted at certification?
At certification the customer declares the deployed quantity of each in scope product, measured for the database in Oracle processors derived from physical cores and the core factor. In a virtualized estate, the question is which physical cores count. Under Oracle's soft partitioning view of VMware, the answer can be every core in every host the Oracle virtual machines could reach, which on a large shared cluster can be a far higher number than the cores actually running Oracle. Because the certified quantity becomes permanent, a customer that counts the entire cluster certifies a large entitlement, while one that counts only the hosts genuinely running Oracle certifies a smaller, more accurate one.
This creates a counterintuitive dynamic unique to certification. Outside a ULA, a high core count is a liability because it means more licences to buy. At certification, a higher legitimately countable core count means a larger permanent entitlement at no extra cost. A customer that has deployed Oracle across a broad virtualized estate during the term, and can defensibly count those cores, may certify a substantial entitlement. The buyer side discipline is to maximise the legitimate count while keeping it defensible, which is exactly the balance described in the certification guide and in Oracle on VMware licensing.
| Context | High core count means | Customer objective |
|---|---|---|
| Outside a ULA | More licences to buy | Minimise countable cores |
| During the term | Irrelevant, deployment unlimited | Virtualize freely |
| At certification | Larger permanent entitlement | Maximise the defensible count |
| After certification | Fixed entitlement on shrinking estate | Right size, consider hard partitioning |
After certification: the estate inverts
Once the customer certifies, the dynamic inverts again. The entitlement is now fixed at the certified quantity, and the unlimited right is gone, so the virtualization question reverts to its ordinary form: the customer wants to run its Oracle workloads on the smallest defensible number of licensed cores. This is where hard partitioning, dedicated Oracle clusters, and careful host placement regain their value, because they let the customer stay within the certified entitlement rather than exceeding it and needing to buy more.
A common post certification mistake is to continue operating the sprawling virtualized estate that made sense during the term, only to find that ordinary growth pushes the deployment past the certified entitlement and creates a compliance gap. The remedy is to right size the estate after certification, isolating Oracle onto controlled infrastructure so that the fixed entitlement comfortably covers actual use. This planning is part of any sound exit strategy and connects to ongoing Oracle audit defence, since post ULA estates are a frequent audit target.
Practical virtualization discipline
The practical programme spans the whole ULA lifecycle. During the term, deploy and virtualize freely for in scope products, but maintain an accurate inventory of where Oracle actually runs, because that inventory is the raw material of the certification count. Approaching term end, model the certification under different counting interpretations, so the customer understands the range between a conservative count and the maximum defensible one, and structures the estate to support the count it intends to declare.
At certification, declare a count that is both maximised and defensible from the customer's own evidence rather than from Oracle's measurement scripts. After certification, right size the Oracle estate onto controlled infrastructure, using hard partitioning where appropriate, so that the fixed entitlement holds. This lifecycle discipline turns virtualization from a source of risk into a lever the customer controls, and it is a standard component of a ULA negotiation and certification engagement.
The buyer side view
The practical takeaway is that virtualization under a ULA is a moving target: irrelevant during the term, decisive at certification, and constraining afterward. The customer that understands this sequence virtualizes freely while the meter is off, maximises a defensible certification count when it matters, and right sizes onto controlled infrastructure once the entitlement is fixed. The customer that treats virtualization the same way throughout either leaves certification value uncaptured or builds an estate it cannot sustain after the ULA ends.
Track where Oracle runs throughout the term, model the certification count under Oracle's partitioning policy, and plan the post certification estate before term end. To work through your own virtualized estate, read the ULA pillar guide and the soft partitioning guide, then engage the ULA negotiation service ahead of certification.
Oracle ULA Virtualization: frequently asked questions
Can I run Oracle on VMware under a ULA?
Yes. During the ULA term, deployment of in scope products is unlimited, so Oracle can run on any VMware cluster without counting processors. The partitioning debate that constrains VMware deployments outside a ULA is effectively suspended for the products on the schedule until certification.
How is VMware counted at ULA certification?
At certification, database deployment is counted in Oracle processors from physical cores and the core factor. Under Oracle's soft partitioning view of VMware, the countable cores can include every host an Oracle virtual machine could run on, so the certified number depends heavily on the estate's structure and the customer's counting position.
Is a high core count good or bad under a ULA?
It depends on timing. Outside a ULA a high core count is a liability because it means more licences. At certification a higher legitimately countable core count means a larger permanent entitlement at no extra cost, so the objective at certification is to maximise the defensible count.
What should I do with virtualization after certifying a ULA?
After certification the entitlement is fixed, so the objective reverts to running Oracle on the smallest defensible number of licensed cores. Right size the estate onto controlled infrastructure, using hard partitioning where appropriate, so ordinary growth does not push deployment past the certified entitlement.