Licensing Oracle Database on Oracle Virtualization (OVM)

For a comprehensive overview of Oracle's approach to virtualization licensing across all platforms, see our guide: Oracle Licensing in Virtual Environments.

1. Oracle Database Licensing on Virtualization: The Basics

Oracle Database licensing is tied to physical hardware capacity. In an on-premises virtual environment, Oracle's default policy is that you must licence all processor cores on any server (or cluster) where an Oracle Database could run — not just the cores the VM actually uses. Simply virtualising Oracle does not reduce your licence requirements.

Oracle draws a critical distinction between soft partitioning and hard partitioning:

Partitioning Type	Definition	Licence Impact	Examples
Soft Partitioning	Virtualization that doesn't strictly bind Oracle to specific CPU cores. Oracle considers VM resource allocations as easily changeable.	No licence reduction. You must cover every core in the host or cluster — regardless of vCPU assignment.	VMware vSphere, Microsoft Hyper-V, generic KVM, Docker containers
Hard Partitioning	Oracle-approved methods of physically limiting Oracle software to a fixed subset of CPU cores. Configuration cannot be easily changed.	Sub-capacity licensing. You only need to licence the cores assigned to Oracle.	Oracle VM (with CPU pinning), Oracle Linux KVM (pinned), IBM LPAR (capped), Solaris Zones

The Partitioning Policy is not part of your contract. Oracle's Partitioning Policy document is a publicly available guideline — not a legally binding contract term. It explicitly states it is "for educational purposes only" and "does not constitute a contract." However, Oracle's audit teams will enforce it as though it were contractual, and most customers lack the leverage to argue otherwise. Your safest approach is to comply with Oracle's partitioning rules while understanding the legal distinction. See Oracle Partitioning Policy — Sub Capacity Licensing Rules.

If your virtualization platform isn't on Oracle's approved hard-partition list, assume it's "soft" and plan to licence the full hardware capacity. This is the backdrop for understanding why OVM is strategically valuable.

2. Why Oracle VM (OVM) Is Different

Most third-party hypervisors — VMware vSphere, Microsoft Hyper-V, generic KVM — are classified as soft partitioning by Oracle. Running an Oracle Database on a VMware cluster means Oracle expects every physical host in that cluster to be fully licensed, even if the VM only runs on a single host. The cost implications can be enormous.

❌ VMware Cluster (Soft Partitioning)

Oracle DB VM with 4 vCPUs on a 4-host cluster (16 cores per host = 64 total cores)

32 licences required

64 cores × 0.5 core factor = 32 processor licences
Estimated: ~$1,520,000

✅ OVM Hard Partition (CPU Pinned)

Same Oracle DB VM pinned to 4 cores on a single OVM host

2 licences required

4 cores × 0.5 core factor = 2 processor licences
Estimated: ~$95,000

Oracle VM (OVM) is Oracle's own hypervisor and one of the few platforms Oracle recognises for hard partitioning when configured correctly. Because Oracle trusts OVM (with proper settings) to confine software to specific cores, licensing can be done on a sub-capacity basis — you licence only the pinned cores, not the entire server.

However, this benefit is not automatic. By default, an OVM environment behaves like any other virtualization platform (soft partitioning) unless you apply specific hard-partitioning configurations. The key requirements are CPU pinning and disabling VM mobility.

OVM does not automatically reduce your licensing. Simply installing Oracle Database on OVM without configuring hard partitioning gives you zero licensing benefit. You must actively pin vCPUs to specific physical cores and disable live migration. Without these steps, Oracle treats OVM identically to VMware — and you must licence every core on the server.

For a complete overview of Oracle's licensing metrics, see Oracle Database Licensing Guide.

3. Hard Partitioning on OVM: How to Do It Right

To use OVM as an Oracle-approved hard partition, you must satisfy two critical requirements:

Pin Virtual CPUs to Physical Cores

Configure the Oracle VM so its vCPUs are bound to specific physical cores on the host. This prevents the VM from "floating" across different cores and ensures Oracle is constrained to a fixed hardware footprint.

Disable Live Migration

Prevent the Oracle VM from migrating to other hosts via OVM's live migration feature. The VM must be locked to a specific host — unless the target host is equally licensed for Oracle.

Document Everything

Capture screenshots, configuration files, and change logs showing CPU pinning settings and host restrictions. This evidence is critical during compliance reviews or Oracle audits.

Implement Change Controls

Establish governance processes so no administrator can increase vCPU allocations, disable pinning, or migrate Oracle VMs without a licence impact review.

Configuration Step	What to Do	Why It Matters
CPU Pinning	In OVM Manager, configure the Oracle VM's virtual CPUs to map to specific physical core IDs. Use the `vcpu_pin` setting to bind each vCPU to a physical CPU.	Without pinning, Oracle cannot verify that the VM is constrained. No pinning = soft partitioning = full host licensing.
Disable Live Migration	Remove the Oracle VM from any migration pools or disable OVM's live migration capability for that specific VM. Alternatively, restrict migration targets to hosts that are already fully licensed.	If the VM can migrate to an unlicensed host — even theoretically — Oracle will require licensing on all potential target hosts.
Isolate Oracle Hosts	Place Oracle VMs in dedicated OVM server pools or on isolated physical hosts that run only Oracle workloads.	Prevents accidental "contamination" where Oracle's licence scope expands to cover non-Oracle infrastructure.
Document and Audit	Record OVM configuration settings (pinning maps, migration policies), retain screenshots, and review settings quarterly.	Provides evidence of compliance if Oracle's LMS team initiates a review. Catches configuration drift early.

The trade-off: flexibility vs. cost. Hard partitioning on OVM means sacrificing some virtualisation benefits — you can't freely move VMs for load balancing or failover. Many organisations find this acceptable for production Oracle databases with stable resource needs. For workloads that genuinely need dynamic mobility, consider Oracle RAC or a pre-licensed standby host instead. See Implementing Oracle-Approved Hard Partitioning.

📄

Oracle Audit Response Toolkit

Step-by-step defence playbook for IT and legal teams. Covers document management protocols, negotiation scripts, and settlement benchmarks drawn from hundreds of enterprise audit engagements.

Download White Paper →

4. Cost Impact: Hard Partitioning vs. Unconstrained Virtualization

The financial difference between correct and incorrect OVM configuration is dramatic. Consider a database VM that needs approximately four cores of processing capacity on a 16-core physical server:

Deployment Scenario	Cores to Licence	Processor Licences*	Estimated Cost†
✅ OVM Hard Partition (4 cores pinned on single host)	4	2	~$95,000
OVM Without Partitioning (16-core host, no CPU pinning)	16	8	~$380,000
❌ VMware Cluster (4 hosts × 16 cores each)	64	32	~$1,520,000

* Assumes 0.5 core factor (standard x86 Intel/AMD processors). Oracle's Core Factor Table determines the multiplier for your specific processor.
† Based on Oracle Database Enterprise Edition at ~$47,500 per processor licence (list price). Actual costs vary based on negotiated discounts.

Properly hard-partitioning the Oracle VM results in a 75% licence reduction compared to running on the same host without pinning, and a 94% reduction compared to an unconstrained VMware cluster. Over the lifetime of the deployment (including ~22% annual support on the licence value), the savings compound into millions.

Real-World Impact: Financial Services Firm

A global bank ran 12 Oracle Database Enterprise Edition instances across a shared VMware cluster with 20 hosts (each with 20 cores). Oracle's LMS team calculated the licensing obligation as 200 processor licences (400 cores × 0.5 core factor) — a potential compliance gap valued at over $9.5 million in licence fees alone. By engaging independent advisers, the bank migrated its Oracle workloads to dedicated OVM hosts with CPU pinning. The final licensed footprint was reduced to 36 processor licences across six isolated hosts — a savings of over $7.6 million in licence costs, plus corresponding annual support savings of approximately $1.67 million per year.

For guidance on choosing between Named User Plus and Processor licensing metrics, see Named User Plus vs. Processor — Which to Choose?.

Running Oracle on VMware? Your Licensing Exposure May Be Millions.

Most enterprises we assess are significantly under-licensed for Oracle in virtualised environments — often without knowing it. Our independent Oracle advisers can map your actual licensing obligation, identify hard-partitioning opportunities, and negotiate with Oracle on your behalf. Fixed-fee engagements. No ties to Oracle.

Oracle Licence Management → Book a Consultation

5. Common Pitfalls to Avoid

Even with Oracle VM's advantages, these common mistakes can eliminate your licensing benefits or create serious compliance exposure:

Pitfall	What Goes Wrong	How to Prevent It
Assuming OVM automatically reduces licences	Team deploys Oracle on OVM without CPU pinning. Oracle treats it as soft partitioning — full host licensing required.	Always verify pinning is configured and documented before claiming sub-capacity licensing.
Mixing Oracle and non-Oracle workloads	Oracle VMs placed in shared OVM pools with other applications. If all hosts aren't licensed, any host the Oracle VM could run on becomes a compliance gap.	Isolate Oracle databases on dedicated OVM hosts or server pools. Keep Oracle separate from general workloads.
Poor documentation	No evidence of CPU pinning or host restrictions during an audit. Oracle's LMS team assumes worst-case (soft partitioning) and demands full-capacity licensing.	Maintain screenshots, config exports, and change logs. Review quarterly. Keep a compliance evidence folder.
Uncontrolled configuration changes	An administrator increases an Oracle VM's vCPUs or migrates it to another host during maintenance — without updating the licence position.	Implement change management: any modification to Oracle VM settings must be reviewed for licence impact before execution.
Forgetting DR and failover hosts	Oracle VM configured correctly on primary host, but a failover or DR host isn't licensed. Oracle migrates during an outage — now you're non-compliant.	Pre-licence any host that could ever run Oracle during failover. Or use Oracle RAC with licensed standby nodes.
Ignoring the OVM to KVM transition	Premier support for OVM ended in 2021. Continuing to run OVM without planning migration creates operational risk.	Plan migration to Oracle Linux KVM (same hard-partitioning benefits) and update licensing documentation accordingly.

Oracle's audit teams specifically target virtualised environments. Virtualization findings are consistently the largest audit exposures Oracle identifies — often resulting in multi-million-dollar compliance claims. During an audit, Oracle's LMS team will request cluster configurations, vCenter screenshots, DR plans, and host inventories. They look for any indication that Oracle could theoretically run on unlicensed hardware. Be prepared to demonstrate your hard-partitioning configuration with clear evidence. See Oracle Licensing in Microsoft Hyper-V for a detailed comparison of how Oracle treats other hypervisors.

6. Recommendations and Checklist

💡 8 Expert Recommendations

1. Use OVM properly: pin Oracle DB VMs to fixed cores and disable their mobility to gain sub-capacity licensing benefits.
2. Isolate Oracle workloads: run Oracle databases in separate OVM clusters or on dedicated hosts to limit the scope of licensing.
3. Limit VM mobility: avoid live-migrating Oracle VMs. If high availability is required, use Oracle RAC or a pre-licensed standby host rather than moving VMs on the fly.
4. Document everything: keep records of how each Oracle VM is configured (CPU pinning, host restrictions) and verify these settings periodically.
5. Educate your team: ensure administrators understand the rules — they shouldn't increase an Oracle VM's CPU allocation or move it to a new host without evaluating the licence impact.
6. Plan for the KVM transition: OVM's premier support ended in 2021. Migrate to Oracle Linux KVM with the same hard-partitioning discipline.
7. Run internal audits: conduct a "dress rehearsal" of an Oracle audit at least annually. Check virtualisation configurations, core counts, and licence entitlements.
8. Engage independent experts: before any major virtualisation migration or Oracle audit response, get independent advice. Oracle's sales and audit teams have different incentives than your organisation.

Inventory all Oracle deployments. List every Oracle Database instance in your organisation and note what infrastructure it runs on — OVM, VMware, physical server, cloud, or other. Identify which environments use soft vs. hard partitioning.
Check OVM configurations. For every Oracle workload on OVM, verify that vCPU pinning is in place and that no automatic live migration can occur for those VMs. Capture evidence.
Enforce hard partitioning. Apply CPU pinning to any Oracle VM that is not already pinned. Move any Oracle workload on non-partitioned environments to dedicated, licensed hardware. Ensure Oracle VMs are isolated to their licensed host or cluster.
Calculate licence requirements. Determine the number of Oracle Processor licences required based on the number of pinned cores (or dedicated hosts) in use. Apply the correct core factor for your hardware. Ensure you have sufficient licences to cover the Oracle footprint as configured.
Document and monitor. Record OVM settings (which cores and hosts Oracle is limited to) and regularly monitor for changes. If something changes — a VM is moved or given more vCPUs — reassess the licensing immediately.

📊 Need help assessing your Oracle virtualisation licensing position?

Get an Assessment →

7. Oracle Linux KVM: The Successor

Oracle is phasing out OVM in favour of Oracle Linux KVM (with Oracle Linux Virtualization Manager, or OLVM). Premier support for OVM ended in 2021, making continued use an operational risk even if existing licences remain valid.

Aspect	Oracle VM (OVM)	Oracle Linux KVM
Status	Legacy — premier support ended March 2021. Extended support may be available at additional cost.	Current — actively developed and supported by Oracle as the go-forward virtualisation platform.
Hard Partitioning	Yes — when vCPUs are pinned and live migration is disabled. Oracle-approved method.	Yes — when vCPUs are pinned and live migration is disabled. Oracle-approved method. Same sub-capacity licensing benefits.
Hypervisor Base	Xen-based hypervisor	KVM-based (integrated into Oracle Linux kernel)
Management	OVM Manager	Oracle Linux Virtualization Manager (OLVM), or direct virsh/libvirt CLI
Migration Path	Oracle recommends migrating to KVM. No automated migration tool — requires manual rebuild or P2V/V2V conversion.	N/A — this is the target platform.
Licensing Benefit	Sub-capacity licensing with correct CPU pinning.	Identical sub-capacity licensing with correct CPU pinning. No change in Oracle's partitioning policy treatment.

Migration from OVM to KVM is not just operational — it's a licensing event. When rebuilding Oracle VMs on Oracle Linux KVM, ensure you maintain the same hard-partitioning discipline: pin vCPUs, disable migration, isolate Oracle hosts, and document everything. The licensing rules are identical, but a migration is the perfect time for configuration drift to introduce compliance gaps. Treat it as a licensing project, not just an infrastructure project. See Oracle Licensing Guide for CIOs and Procurement.

📄

CIO Playbook: Structuring Your Oracle Commercial Relationship

A strategic guide covering governance frameworks, negotiation sequencing, vendor relationship management, and how to build internal capabilities that permanently shift the balance of power away from Oracle's sales organisation.

Download White Paper →

Facing an Oracle Virtualisation Audit?

Virtualisation findings are consistently the largest compliance claims Oracle identifies — often resulting in multi-million-dollar exposure. Our independent Oracle audit defence experts have defended hundreds of enterprises. We assess your compliance position, remediate gaps before Oracle finds them, and negotiate the best possible resolution on your behalf.

Oracle Audit Defence → Contract Negotiation Service

Frequently Asked Questions

Yes — but only by using OVM's hard-partitioning features. If you pin an Oracle Database VM to 4 out of 16 cores on a host, you can purchase licences for just those 4 cores (with the appropriate core factor applied). Without hard partitioning, Oracle requires licensing all 16 cores of that server. The key is that CPU pinning must be explicitly configured and documented. See Implementing Oracle-Approved Hard Partitioning.

OVM can limit licence requirements if used correctly, whereas VMware cannot in Oracle's eyes. Oracle doesn't recognise VMware's CPU affinity or other controls as valid limits — on VMware, you must generally licence every core on every host where Oracle might run. With OVM (or Oracle Linux KVM) configured as a hard partition, Oracle officially allows you to licence only the cores you dedicate to the Oracle VM. This distinction can result in licence savings of 75% or more. See Oracle Licensing in Microsoft Hyper-V for how Oracle treats another common hypervisor.

Not unless the target host is equally licensed. In practice, you should avoid live-migrating an Oracle VM to any host that isn't already licensed for all its cores. If you need failover or migration capability, consider licensing a secondary OVM host in advance, or use Oracle's clustering solutions (Oracle RAC) rather than migrating VMs to unlicensed servers.

Yes — Oracle is phasing out OVM in favour of Oracle Linux KVM (with Oracle Linux Virtualization Manager). Premier support for OVM ended in 2021. From a licensing perspective, Oracle Linux KVM with proper CPU pinning is treated identically to OVM — it offers an Oracle-approved hard-partitioning method. The same sub-capacity licensing principles apply. However, the migration itself is a licensing event that requires careful management to maintain compliance.

Oracle's Partitioning Policy document is the primary source — it outlines hard vs. soft partitioning rules and lists which technologies Oracle approves for sub-capacity licensing. You should also consult Oracle's Database Licensing Guide (available on Oracle's pricing pages) and relevant Oracle Support notes on virtualization. For independent analysis, see Oracle Partitioning Policy — How to Push Back.

Oracle's Core Factor Table assigns a multiplier to different processor types. For most modern x86 Intel and AMD processors, the core factor is 0.5, which effectively halves the number of processor licences needed. For example, if you pin an Oracle VM to 4 physical cores on an x86 server, you need 4 × 0.5 = 2 processor licences. The core factor is critical to accurate cost calculations and must be verified against Oracle's published table for your specific hardware. See Oracle Database Licensing Guide.

Yes — Oracle requires licensing for all environments where Oracle Database is installed and/or running, including development, test, staging, and production. There is no "free" tier for non-production use (with the limited exception of Oracle's OTN Developer Licence for individual personal use). If you run development or test Oracle databases on OVM, the same hard-partitioning rules apply: pin vCPUs and disable migration to benefit from sub-capacity licensing.

No. Oracle considers containers as soft partitioning. Running Oracle Database inside a Docker container on an OVM host does not provide any additional licensing reduction beyond what OVM's hard partitioning already offers. The licensing obligation is determined by the underlying host configuration — if OVM is properly hard-partitioned with CPU pinning, that's what determines your licence count, regardless of whether containers are used within the VM.

Oracle's LMS (Licence Management Services) team typically requests cluster configurations, host inventories, VM configurations, DR plans, and evidence of any partitioning. They use Oracle's licence review scripts to collect technical data from your databases. For virtualised environments, they'll look for evidence that Oracle VMs are properly constrained — or conversely, that they could potentially access unlicensed hosts. Without clear documentation of hard partitioning, Oracle will assume the worst-case (soft partitioning) scenario and demand full-capacity licensing across your infrastructure.

It depends on your strategy. Moving Oracle to dedicated physical servers eliminates virtualisation licensing complexity entirely — you simply licence the cores on the physical box. Alternatively, migrating to Oracle Cloud Infrastructure (OCI) shifts licensing responsibility to Oracle's cloud model. Each approach has trade-offs in flexibility, cost, and operational complexity. If you stay on virtualised infrastructure, OVM or Oracle Linux KVM with proper hard partitioning remains the most cost-effective approach.

🔗 Oracle Official Resources

For Oracle's own documentation on partitioning and licensing, refer to these vendor-published resources:

Oracle Partitioning Policy Document (PDF)
Oracle Processor Core Factor Table
Oracle Technology Global Price List
Oracle Virtualization Products

📄 Oracle White Papers & Resources

📚 Oracle Licensing Knowledge Hub 📄 All White Papers

Oracle Advisory Services

🏢 Oracle Licence Management 🛡️ Oracle Audit Defence 🤝 Oracle Contract Negotiation 📊 Oracle Advisory Services

Fredrik Filipsson

Co-Founder @ Redress Compliance

20+ years in enterprise software licensing. Former IBM, SAP, and Oracle. 11 years as an independent consultant advising hundreds of Fortune 500 companies on Oracle, Microsoft, SAP, IBM, and Salesforce licensing, contract negotiations, and cost optimisation.

LinkedIn · View All Posts