Oracle VM (OVM) Licensing Guide: Hard Partitioning, Guest VM Rules, and Compliance

What Oracle VM Is and Its Strategic Role in Enterprise Licensing

Oracle VM Server for x86, commonly referred to as OVM, is Oracle's proprietary hypervisor based on the open-source Xen hypervisor. It provides virtualisation capabilities on x86 servers, allowing organisations to consolidate multiple operating systems and applications onto a single physical server. OVM is distinct from Oracle Linux KVM, which is Oracle's newer virtualisation approach based on the Kernel-based Virtual Machine (KVM) technology integrated into Oracle Linux.

OVM has occupied a unique position in Oracle's licensing framework since its introduction over a decade ago. The hypervisor itself is free software with no separate licensing cost. The critical licensing value of OVM is not the hypervisor itself but rather Oracle's contractual approval of OVM for hard partitioning, which is a specific virtualisation architecture where virtual machine vCPUs are physically pinned to specific physical cores, preventing the VM from accessing other cores dynamically.

Hard partitioning creates substantial licensing advantages for organisations running Oracle software in virtualised environments. Under hard partitioning with OVM, you license only the physical cores that are assigned to Oracle-running virtual machines, not the entire physical server. This can reduce licensing costs by 60 to 80 percent compared to soft partitioning environments such as VMware or Hyper-V, where the entire physical server must be licensed because the hypervisor can dynamically move VMs across all available cores.

It is important to note that OVM has entered sustaining engineering status. Oracle's investment in new feature development for OVM has largely ceased. Oracle has strategically shifted its virtualisation investment to Oracle Linux KVM, which also qualifies for hard partitioning but with more prescriptive configuration requirements than OVM. Most new deployments are Oracle Linux KVM; OVM remains supported for existing customers but is not Oracle's primary hypervisor recommendation for new environments.

Hard Partitioning vs. Soft Partitioning: Fundamental Licensing Distinction

The distinction between hard partitioning and soft partitioning is the single most consequential decision in Oracle licensing within virtualised environments. This distinction determines whether you license a portion of a server or the entire server, and the cost difference is often enormous.

Hard Partitioning means that virtual machine vCPUs are physically bound to specific physical processor cores. The binding is not merely a configuration preference; it is an architectural constraint enforced at the hypervisor level. A VM configured with 8 vCPUs pinned to physical cores 0 through 7 cannot access cores 8 through 31 on the same physical server, even during periods of high resource demand. The pinning is permanent and enforced by the hypervisor itself, not by the operating system or application running inside the VM.

Soft Partitioning means that virtual machine vCPUs can dynamically float across the entire set of physical cores available in the server. The hypervisor scheduler can move a vCPU from one physical core to another based on current workload and resource contention. VMware vSphere, Microsoft Hyper-V, and standard Kernel-based Virtual Machine (KVM) implementations all use soft partitioning by default. In a soft partitioning environment, every physical core in the server is considered "available" to every VM because the scheduler can assign any VM to any core at any moment.

Oracle's licensing policy directly follows this architectural distinction: hard partitioning allows sub-capacity licensing (licence only the cores assigned to Oracle workloads), while soft partitioning requires full-server licensing (licence all cores in the server because any VM can theoretically use any core).

Oracle's approved hard partitioning platforms are explicitly listed in Oracle's licensing documentation. OVM is on the approved list. VMware, Hyper-V, and standard KVM configurations are not on the approved hard partitioning list. This means if you run Oracle software on VMware or Hyper-V, you must licence all physical cores in the server, regardless of how many vCPUs you actually assign to Oracle workloads.

OVM Hard Partitioning Requirements: Three Mandatory Elements

To qualify for hard partitioning licensing under Oracle's policy, three mandatory requirements must be met simultaneously. Failure to meet any one requirement means Oracle LMS will reclassify your deployment as soft partitioning and demand full-server licensing for all Oracle workloads.

Requirement 1: CPU Pinning Must Be Configured and Enforced. vCPUs assigned to Oracle VMs must be pinned to specific physical cores within OVM Manager. The pinning must be configured in OVM Manager's VM configuration interface, not simply specified in the guest operating system or enforced through administrative process. OVM Manager provides a CPU affinity setting (sometimes called "vcpu_hard_affinity" in OVM technical documentation) that binds specific vCPUs to specific physical cores.

The pinning configuration must be documented and verifiable. During an Oracle audit, LMS will request OVM Manager exports, VM configuration files, and evidence that the CPU pinning is configured. Screenshots showing the OVM Manager interface are helpful but insufficient; Oracle requires exportable configuration data that proves pinning is active in the hypervisor itself.

Requirement 2: Live Migration Must Be Disabled or Restricted. Oracle's policy requires that live migration (the ability to move a running VM from one physical host to another without downtime) be disabled for Oracle VMs, or be restricted to destination hosts that are licensed to the same level as the source host.

The licensing rationale is clear: if an Oracle VM is pinned to cores on Host A but live migrates to Host B, the VM can potentially access different physical cores on Host B, violating the pinning assumption. To maintain hard partitioning integrity, Oracle requires that migration either be impossible or that both source and destination hosts are licensed for Oracle at the same level.

In practice, this requirement is often the most frequently violated in OVM deployments. Organisations often configure Oracle VMs with live migration enabled for operational resilience and high availability, without realizing this violates the hard partitioning requirement. When Oracle LMS discovers migration logs showing Oracle VMs moving between hosts, LMS typically demands retroactive licensing for all cores on all destination hosts from the time of migration.

Requirement 3: The VM Must Not Be Able to Access Physical Cores Beyond Those Assigned. Beyond configuration settings, there must be no technical pathway for a VM to consume physical cores beyond those pinned in OVM Manager. This is typically the case when CPU pinning is properly configured at the hypervisor level, but the requirement emphasizes that pinning must be enforced at the hypervisor layer, not merely at the OS or application layer.

During audits, Oracle LMS may request system topology information, core numbering details, and OVM Manager host configuration to verify that pinning is technically enforced. If a VM is configured with 8 pinned vCPUs but the host has 32 physical cores and the pinning configuration appears incomplete or incorrectly specified, Oracle will assume the VM can access all 32 cores and demand licensing accordingly.

Counting Oracle Licences Under Hard Partitioning

Once hard partitioning is properly configured and documented, the licence count is straightforward. Oracle applies a core factor of 0.5 to x86 processors, meaning 2 physical cores equal 1 Oracle processor licence.

The calculation: count the number of physical cores pinned to Oracle VMs in OVM Manager, divide by 2 (the x86 core factor is 0.5, so 1 licence covers 2 cores), and that is your processor licence requirement.

Example: a physical server has 32 physical cores. You configure 4 Oracle Database VMs, each pinned to 8 physical cores, for a total of 32 cores pinned to Oracle workloads. Your licence requirement is 32 / 2 = 16 Oracle Database processor licences.

Compare this to soft partitioning: the same 32-core server, even if you only run Oracle on 8 vCPUs (soft partitioned), would require 32 / 2 = 16 Oracle Database processor licences because all 32 physical cores are "available" to the Oracle VMs under soft partitioning and therefore must all be licensed.

For OVM hard partitioning, the savings come when you have excess server capacity. Example: a 32-core server where you only run Oracle workloads on 8 pinned vCPUs requires 8 / 2 = 4 Oracle Database processor licences, while the remaining 24 cores (12 licences) are unlicensed. This is the economic model that makes OVM attractive for many organisations.

OVM Manager Configuration and CPU Pinning in Practice

OVM Manager is Oracle's centralised management platform for OVM hosts and virtual machines. It provides a graphical interface for configuring VMs, managing virtual networking, monitoring host resources, and setting up high availability and disaster recovery.

CPU pinning is configured per VM within OVM Manager. When creating or modifying a VM, the CPU affinity tab allows you to specify which physical cores the VM's vCPUs are pinned to. The interface typically shows a diagram of the host's physical cores and allows you to select specific cores for the VM to use.

The pinning must be configured explicitly; OVM does not default to pinning. A VM created in OVM without explicit CPU affinity configuration will have its vCPUs scheduled dynamically across all available cores, which constitutes soft partitioning. Oracle licensing compliance requires verifying that every Oracle VM in your environment has CPU affinity configured, and that the configuration accurately reflects the intended hard partitioning design.

During compliance audits, it is essential to export OVM Manager configuration reports showing CPU affinity settings for all Oracle VMs. These exports provide defensible evidence that pinning was configured and enforced. Text-based configuration exports (often available in OVM Manager's reporting features) are more credible than screenshots, as they are harder to fabricate and demonstrate the actual hypervisor configuration state.

Live Migration and High Availability Licensing Implications

OVM HA (high availability) is a valuable feature that allows VMs to automatically restart on another host if the primary host fails. However, HA interacts with hard partitioning in ways that create licensing risks if not carefully managed.

The scenario: you have two OVM hosts, each with 32 physical cores. You want to run a critical Oracle Database VM with 8 vCPUs pinned to Host A's cores 0-7. You also want HA failover enabled so that if Host A fails, the Database VM automatically restarts on Host B. What happens licensing-wise if the failover occurs?

Under Oracle's hard partitioning policy, if the Oracle Database VM fails over to Host B, the VM may access Host B's cores dynamically during the failover and restart process, violating the pinning assumption. To maintain hard partitioning integrity, Oracle requires one of two approaches:

Approach 1: Disable Live Migration and HA for Oracle VMs. The simplest approach is to configure OVM so that Oracle VMs do not support live migration and do not participate in HA failover. This preserves the hard partitioning model but sacrifices operational resilience. If the host running an Oracle VM fails, the VM stops and must be restarted manually on another host.

Approach 2: License Destination Hosts for HA Failover. If HA failover is operationally critical, you can maintain hard partitioning by ensuring that all potential HA destination hosts are licensed at the same level as the primary host. If the Oracle Database VM is pinned to 8 cores on Host A, you must license 8 cores (4 processor licences) on Host B as well, even though the Database VM normally does not run on Host B. This accounts for the possibility of failover.

The licensing cost of HA for Oracle workloads can be substantial. If you have 10 OVM hosts in an HA cluster, all capable of failover destinations for Oracle VMs, you may need to license Oracle on all 10 hosts to account for potential failover scenarios. Many organisations find this uneconomical and instead disable HA for Oracle workloads.

During audits, Oracle LMS will request HA configuration details, VM failover policies, and host licensing records. If LMS discovers Oracle VMs with HA enabled but no evidence that destination hosts are licensed for Oracle, LMS will typically demand retroactive licensing for the destination hosts.

Oracle Linux KVM as OVM's Strategic Successor

Oracle has invested heavily in Oracle Linux KVM as the successor platform to OVM. KVM is integrated directly into Oracle Linux rather than provided as a separate hypervisor product. KVM is also on Oracle's approved hard partitioning list, meaning it qualifies for sub-capacity licensing equivalent to OVM.

However, KVM's hard partitioning requirements are more prescriptive than OVM's. Oracle's KVM hard partitioning guidance specifies the use of specific libvirt configuration parameters (the libvirt library manages KVM virtual machines). The pinning equivalent in KVM is the "cpuset" configuration in libvirt XML VM definitions. Oracle requires that the cpuset configuration be present and correct for each VM.

For organisations migrating from OVM to Oracle Linux KVM, the migration preserves hard partitioning eligibility but requires reconfiguration. You cannot simply move an OVM VM to KVM and expect the same licensing model to apply; you must reconfigure the VM's CPU pinning in KVM's libvirt format.

If you are evaluating new virtualisation platforms for Oracle workloads, KVM is a viable hard partitioning option. However, KVM has a smaller market share than VMware and Hyper-V, which means fewer third-party tools, less broad vendor support integration, and a smaller ecosystem of operational expertise. The licensing advantage of hard partitioning must be weighed against operational and support considerations.

Common OVM Licensing Mistakes and Audit Exposure

Based on audit findings across many organisations, here are the most frequent OVM licensing mistakes:

Mistake 1: Assuming OVM Always Qualifies for Hard Partitioning Without Verification. The most dangerous assumption is that simply running Oracle on OVM automatically means hard partitioning applies. In reality, hard partitioning requires all three requirements to be met and documented. Many organisations have discovered during audits that their OVM VMs lacked CPU affinity configuration, meaning they were operating under soft partitioning rules and owed retroactive licensing for entire server cores.

Mistake 2: Enabling Live Migration Without Licensing Destination Hosts. Organisations often enable OVM HA and live migration for operational resilience without realizing this violates the hard partitioning requirement. When an Oracle VM migrates to an unlicensed destination host, the entire destination host becomes liable for Oracle licensing retroactively from the time of migration.

Mistake 3: Running Oracle and Non-Oracle Workloads on the Same Host Without Isolation. If a host runs both Oracle and non-Oracle workloads without explicit CPU affinity pinning for each, Oracle will treat the entire host as subject to Oracle licensing. You must pin Oracle VMs to specific cores and document that non-Oracle VMs are pinned to other, separate cores.

Mistake 4: Losing Documentation of CPU Pinning Configuration. Many organisations configure CPU affinity in OVM Manager years ago, but the documentation of that configuration is not maintained. During audits, if you cannot produce evidence that pinning was configured, Oracle will assume it was not and reclassify the deployment as soft partitioning.

Mistake 5: Reconfiguring or Removing CPU Affinity Without Understanding the Licensing Impact. If a system administrator reconfigures a VM and inadvertently removes the CPU affinity setting, the VM shifts from hard partitioning to soft partitioning. This can happen silently and go undetected for months until an audit reveals the licensing gap.

OVM and Oracle Database Options

Oracle Database options (Advanced Compression, Partitioning, Real Application Clusters, etc.) must be licensed for all processor licences allocated to the option-using VMs. If a Database instance running in an OVM hard-partitioned VM uses the Advanced Compression option, all processor licences allocated to that VM must include the Advanced Compression licence. Advanced Compression costs approximately $11,500 per processor licence.

The hard partitioning cost calculation remains the same (cores assigned / 2), but the per-licence cost increases if the VM uses options. This must be factored into capacity planning: a VM pinned to 16 cores requires 8 base Database licences plus the cost of any options (e.g., Advanced Compression) applied to those 8 licences.

Audit Experience and OVM Audit Scope

When Oracle LMS conducts an audit involving OVM deployments, the scope is typically the entire OVM cluster or all OVM hosts containing Oracle workloads, not just the individual servers where Oracle software is installed. LMS will request OVM Manager exports, host configuration data, VM configuration files, and migration logs spanning multiple years (typically 3 to 5 years).

LMS will reconstruct the historical state of the virtualisation environment, identify all Oracle deployments across the cluster, verify that CPU affinity was configured for each Oracle VM throughout the audit period, and confirm that destination hosts for migrated VMs were appropriately licensed.

The audit process often reveals gaps where pinning was configured initially but later removed during VM reconfiguration, or where HA failover created unlicensed liability on destination hosts. Oracle typically demands retroactive licensing fees covering the period from when the gap occurred until the audit date, plus penalties and interest in some cases.

Support Fees and Cost of Ownership Under OVM

Oracle VM itself is free software. There is no separate licensing cost for the hypervisor. However, Oracle Database licences running on OVM are subject to the same support fee structure as Database on any other platform: 22 percent of the net licence value annually, with 8 percent annual escalation.

The hard partitioning cost reduction applies to licence fees but not proportionally to support fees. If hard partitioning reduces your licence count from 32 to 8 processor licences (a 75 percent reduction in licence count), your support fees will also be approximately 75 percent lower than they would be under soft partitioning. However, support fees still increase by 8 percent annually, and your total cost of ownership over 10 years compounds substantially.

Six Priority Recommendations for OVM Compliance

1. Audit Your Current OVM Deployments. Engage an independent Oracle licensing advisor to review all OVM hosts, VMs, and CPU affinity configurations. Identify any VMs lacking proper CPU pinning, any hosts with live migration enabled for Oracle VMs, and any historical evidence of migration to unlicensed destinations. Address gaps proactively.

2. Document CPU Affinity Configuration Comprehensively. Export OVM Manager configuration reports showing CPU affinity for all Oracle VMs. Maintain this documentation in a central repository and update it annually. This documentation becomes invaluable if Oracle conducts an audit and requests evidence of pinning.

3. Disable Live Migration for Oracle VMs, or Ensure HA Destination Hosts Are Licensed. Make an explicit operational decision: either disable HA and live migration for Oracle workloads to preserve hard partitioning and avoid additional licensing, or accept the cost of licensing destination hosts that can serve as HA failover targets. Do not default to enabled HA without understanding the licensing implications.

4. Create a Register of All Oracle VMs and Their Pinned Cores. Maintain a spreadsheet listing every Oracle VM, the cores it is pinned to, the processor licences required, and the host it resides on. Update this register whenever VMs are added, migrated, or reconfigured. Cross-reference this register to your licence entitlements quarterly to identify any gaps.

5. Implement Change Control for OVM VM Configuration. Establish a process requiring approval before any changes to VM CPU affinity, host assignment, or HA status. Many licensing gaps arise from administrators reconfiguring VMs without understanding the licensing impact. Change control creates a checkpoint.

6. Plan Migration to Oracle Linux KVM for Sustainability. Since OVM is in sustaining engineering, plan a multi-year migration of Oracle workloads to Oracle Linux KVM. KVM provides equivalent hard partitioning capabilities but with newer technology and ongoing investment. The migration preserves licensing benefits while positioning your infrastructure for long-term support.