Oracle's Partitioning Policy: The Document That Controls Everything

Oracle published its official Partitioning Policy in January 2017, and this document remains the authoritative reference that Oracle License Management Services uses to determine whether your virtualisation configuration limits your licence count or requires full physical host licensing. The policy distinguishes between two categories: hard partitioning, which uses technology that physically restricts Oracle software to a defined set of processors, and soft partitioning, which uses software-based resource allocation that can be changed dynamically or overridden without hardware reconfiguration.

The critical principle underlying Oracle's position is not whether Oracle software is currently running on all hosts, but whether it could run on all hosts. If you have deployed a virtual machine on a VMware cluster with 20 hosts and that VM could theoretically be vMotioned to any of those 20 hosts, Oracle's licensing position is that all 20 hosts must be licensed for Oracle software. This principle applies regardless of your actual workload distribution. For organisations managing large VMware estates, this means the difference between licensing a 4 node cluster and licensing every server in a sprawling hypervisor management domain. Understanding the distinction is not optional — it is the foundation of a compliant and cost-optimal Oracle virtualisation strategy. For detailed guidance, see our Oracle Virtualisation Licensing guide.

Hard Partitioning Technologies That Oracle Accepts

Oracle recognises 17 distinct hard partitioning technologies across Unix, Linux, x86, and legacy SPARC platforms. The key requirement for all of them is the same: processors must be assigned to a partition in a way that cannot be changed dynamically without a configuration change that involves stopping workloads or rebootting hardware. Oracle VM for x86, which is Oracle's native hypervisor, qualifies as hard partitioning only when deployed with CPU pinning — meaning processors are dedicated to specific VMs and cannot be reallocated at runtime. An Oracle VM deployment using shared CPU pools, where capacity can be dynamically redistributed among VMs, provides no hard partitioning benefit and must be licensed as soft partitioning.

The full list of Oracle-accepted hard partitioning technologies includes Oracle VM for x86 (with dedicated CPU pools only), Oracle VM for SPARC (using logical domains with dedicated CPU threads), IBM LPAR on AIX (only dedicated processor pools, not shared capped pools), HP-UX vPar (on Integrity servers), Fujitsu PPAR (on Fujitsu UNIX systems), Hitachi LPAR (on SPARC systems), Solaris 11 Zones (with exclusive CPU binding), and Solaris 10 Containers (limited acceptance). Each of these requires strict adherence to configuration rules. For AIX-based Oracle deployments, a configuration using shared LPAR pools does not qualify; the LPAR must be in dedicated mode with fixed processor assignments. For Solaris Zones, the zone must use exclusive CPU assignment, not shared pools. The critical configuration requirement for Oracle VM is CPU pinning specifically — a pinned vCPU cannot be migrated at runtime without explicit configuration change.

Soft Partitioning Technologies and Their Licensing Implications

The soft partitioning category encompasses the majority of virtualisation platforms in use today: VMware vSphere ESXi (all versions), Microsoft Hyper-V (all versions), Linux KVM, Citrix XenServer, AWS EC2 standard instances, Azure standard VMs, Google Compute Engine, Docker, Kubernetes, and all public cloud services that do not use dedicated hardware. Each of these allows dynamic resource reallocation, vMotion between hosts, or runtime placement without explicit configuration change. Solaris Resource Manager, Solaris Projects, AIX Workload Partitions (WPARs), and HP-UX vPar with shared processor pools are all classified as soft partitioning even though they run on platforms traditionally associated with hard partitioning.

The licensing consequence of soft partitioning is unambiguous: you must license all physical processors on all servers in the cluster, or if servers are managed by a common hypervisor management layer (such as a vCenter instance), potentially all servers under that management domain. For a VMware environment with eight nodes, each containing two Intel sockets with 24 cores each (48 cores per node, 384 total cores), you must licence 384 physical cores. At Oracle's standard 0.5 core factor for Intel processors, this translates to 192 Oracle Processor licences regardless of how many virtual machines you deploy or how few of those machines run Oracle software. This calculation applies to the entire cluster under a single vCenter management domain, not to individual hosts or resource pools.

The Oracle LMS Audit Approach to Partitioning

During an LMS audit, the audit team's first investigation is always the virtualisation infrastructure topology. For VMware environments, LMS requests complete vCenter exports including Distributed Resource Scheduler configuration, HA failover rules, and vMotion history for the preceding 12 months. For LPAR environments, LMS requests Hardware Management Console exports showing processor pool assignments, whether pools are in shared or dedicated mode, and the history of configuration changes. For Oracle VM deployments, LMS specifically reviews CPU pinning configuration to verify that vCPUs assigned to Oracle workloads are actually pinned and cannot be dynamically reallocated.

What LMS looks for specifically is evidence that would invalidate a hard partitioning claim. Shared CPU pools in an Oracle VM environment directly contradict the CPU pinning requirement. vMotion history showing Oracle VMs migrated between unlicensed hosts indicates that those hosts should have been licensed. High Availability failover events where an Oracle VM migrated to an alternate host suggest that the alternate host could host the Oracle workload and therefore should be licensed. An LPAR configuration where processor mode is set to shared rather than dedicated immediately disqualifies the hard partitioning claim. The audit assessment determines licence gaps based on this evidence, and the financial impact can be substantial — a gap of 10 Oracle servers in a 200-core cluster can result in audit exposure of 100+ processor licences.

Achieving a Compliant Hard Partitioning Configuration

The most straightforward path to compliant hard partitioning for Oracle on x86 is Oracle VM for x86 with CPU pinning. Oracle provides the hypervisor at no cost; the infrastructure investment is in dedicated physical servers configured exclusively for Oracle workloads. For an organisation running Oracle Database across multiple tiers (production, staging, development), a two to four node Oracle VM cluster with CPU-pinned virtual machines can consolidate multiple database instances while limiting licence counts to the specific CPUs assigned to each VM. This approach eliminates the cluster-wide licensing exposure of VMware or Hyper-V and provides a compliant foundation for Oracle workload consolidation.

The second path is Oracle Autonomous Database on Oracle Cloud Infrastructure with BYOL, which provides the same sub-capacity counting benefit as hard partitioning without the on-premises hypervisor management complexity. OCI VM shapes with BYOL allow you to count only the OCPUs in the specific shape running your database, and because OCI is a managed cloud service, no cluster-wide licensing applies. For organisations whose strategic direction includes cloud migration, this approach eliminates both the infrastructure investment in Oracle VM and the ongoing management overhead. The migration path is relatively straightforward for organisations already rationalising their Oracle Database estate, and the licence counting advantage is immediate. See our Oracle BYOL to OCI guide for detailed TCO comparison.

The third path, available to IBM AIX customers, is to configure AIX LPARs with dedicated processor pools rather than shared capped pools. Organisations running Oracle Database Enterprise Edition on AIX already have the hard partitioning technology available — the configuration change is straightforward (reconfigure the LPAR from shared to dedicated mode), and the licence counting impact can be transformative. A server with 64 cores running four dedicated LPARs with 16 cores each means you licence only 16 cores per LPAR, not the full 64 cores of the host. This path requires validation of the AIX configuration and coordination with platform teams, but the compliance gain is immediate and the financial impact is measurable. For strategy and implementation guidance, see our Oracle TCO optimisation guide.