What Is Hard Partitioning and Why It Matters
Hard partitioning physically segments a server's CPU resources so that a defined, fixed subset is dedicated to Oracle software. Unlike soft partitioning — where virtualisation technologies can dynamically redistribute resources — hard partitioning creates immovable boundaries that Oracle accepts as the licensing scope. You licence only the cores inside the partition, not the entire physical server.
For enterprises running Oracle on large multi-core servers, the financial impact is enormous. Without hard partitioning, Oracle requires licensing every core in the physical server or cluster where Oracle is installed — even if Oracle uses only a fraction of those cores. Hard partitioning is the only Oracle-recognised method to avoid this full-server licensing requirement in virtualised or partitioned environments.
Licence Cost Reduction
Licence only the cores in the partition, not the full server. On a 32-core server with an 8-core partition, you licence 8 cores instead of 32 — a 75% reduction.
Audit Defence
Oracle-approved hard partitioning creates a defensible licensing position. During audits, documented partition configurations serve as evidence of compliance.
Fixed Resource Boundaries
Hard partitions are static — Oracle workloads cannot accidentally consume more cores than allocated, keeping licence requirements predictable and stable.
VMware Excluded
VMware is classified as soft partitioning regardless of configuration. No VMware CPU affinity, reservation, or limit setting is accepted by Oracle as hard partitioning.
"The difference between hard partitioning and soft partitioning is not a technicality — it is the difference between licensing 8 cores and licensing 128 cores on the same server. In every major Oracle audit we have supported, the partitioning classification of virtualised environments is the single largest source of compliance exposure and unexpected cost."
Oracle-Approved Hard Partitioning Technologies
Oracle maintains an explicit list of technologies it classifies as hard partitioning. Only these methods allow sub-capacity licensing. Using any technology not on this list — regardless of how restrictively you configure it — means Oracle will require licensing of the entire physical server or cluster.
| Technology | Platform | Key Configuration Requirement | Oracle Acceptance |
|---|---|---|---|
| Oracle VM (OVM) with CPU Pinning | x86 (Oracle Linux) | VMs must be pinned to specific physical cores; CPU affinity must be fixed and persistent | ✅ Approved — only with hard CPU pinning enabled |
| Oracle Linux KVM with CPU Pinning | x86 (Oracle Linux) | Same as OVM — vCPUs must be pinned to specific host cores using libvirt/virsh configuration | ✅ Approved — only with hard CPU pinning |
| IBM LPAR (Capped Mode) | IBM Power (AIX, Linux) | LPAR must be configured with a hard cap on processing units — uncapped LPARs are NOT accepted | ✅ Approved — capped mode only |
| Solaris Zones (Capped) | Oracle Solaris (SPARC, x86) | Zone must be configured as "capped-cpu" with a fixed number of dedicated CPUs | ✅ Approved — capped zones only |
| Physical Domains (PDoms) | SPARC (T-series, M-series) | Hardware-level domain isolation — each domain operates as an independent physical partition | ✅ Approved — hardware-enforced |
| HPE nPartition (nPar) | HPE Integrity / Superdome | Firmware-level partition — each nPar is electrically isolated at the cell board level | ✅ Approved — firmware-enforced |
| Fujitsu PPAR | Fujitsu SPARC / PRIMEQUEST | Processor partitioning with hardware isolation and capped CPU allocation | ✅ Approved — with proper capping |
| VMware vSphere (all versions) | x86 | No configuration is accepted — CPU affinity, reservations, limits, and resource pools are all classified as soft partitioning | ❌ NOT approved — full server licensing required |
Critical distinction: Oracle's partitioning policy is a unilateral policy document, not a contractual term. It is not part of your licence agreement. However, Oracle LMS (Licence Management Services) enforces it during audits, and most enterprises comply with it to maintain a defensible position. If you believe your contract terms differ from the policy, consult independent licensing advisers — the contractual language may provide additional rights that Oracle's policy does not acknowledge.
Configuration Best Practices: Making It Audit-Proof
Using an approved technology is necessary but not sufficient. Oracle will only accept the partitioning if the configuration meets specific criteria. A poorly configured approved technology is treated the same as an unapproved technology — full server licensing.
Enable Hard Caps — Not Soft Limits
Every partition must have a fixed maximum number of CPU cores that cannot be exceeded under any circumstances. For IBM LPARs, this means capped mode with maximum processing units defined. For OVM, this means CPU pinning to specific physical cores. Soft limits, resource pools, and "priority" settings are not sufficient — the partition must be physically or logically incapable of exceeding the defined core count.
Ensure Persistence Across Reboots
Partition settings must survive server restarts, firmware updates, and maintenance windows. If a reboot resets the CPU pinning or uncaps an LPAR, the server runs at full capacity until the configuration is restored — and Oracle can claim you needed full licensing for that period. Automate configuration enforcement and validate settings after every restart event.
Restrict VM Mobility
If you use Oracle VM with CPU pinning, the VM must not migrate (vMotion-equivalent) to a host where it is not identically pinned. Live migration to an unpinned host invalidates the hard partitioning for the entire period the VM ran unpinned. Disable live migration for Oracle VMs, or ensure every potential target host has identical pinning configurations. Document the migration policy and enforce it through hypervisor settings.
Document Everything — Continuously
Maintain a "licence evidence binder" for every Oracle deployment that relies on hard partitioning. Include: configuration screenshots from the management console, command-line output showing CPU allocation (e.g., lparstat for IBM, virsh vcpupin for KVM), hostnames, partition names, core counts, and timestamps. Update this documentation after every change. Oracle audits can request historical configurations — not just the current state.
Lock Down Administrative Access
Restrict the ability to modify partition settings to a small number of authorised personnel. If an operations administrator increases an LPAR's CPU cap to resolve a performance issue — even temporarily — the licensing position changes immediately. Implement role-based access controls and change management approvals for any modification to Oracle-related partition configurations.
Real-World Example: 75% Licence Savings Through Solaris Zones
Financial Services Company: $570K Saved on a Single Server
Situation: A financial services company ran Oracle Database Enterprise Edition on a 32-core SPARC server (core factor 0.5). Without partitioning, the full server required 16 Processor licences at $47,500 each = $760,000 in licences plus $167,000/year in support.
Implementation: The company configured a capped Solaris Zone dedicated to Oracle, limited to 8 physical cores. The remaining 24 cores ran non-Oracle workloads. Oracle's core factor of 0.5 applied to the 8-core zone, requiring only 4 Processor licences.
Second Example: IBM LPAR Saves $285K
A healthcare organisation ran Oracle Database EE on an IBM Power9 server with 32 cores (core factor 1.0 for Power architecture). Full-server licensing would require 32 Processor licences = $1,520,000. By creating a capped LPAR limited to 12 cores, the organisation licensed only 12 Processors = $570,000 — saving $950,000 in licence cost. The capped LPAR was documented via HMC (Hardware Management Console) screenshots and lparstat -i output showing the entitled capacity ceiling. At audit, Oracle accepted the configuration without challenge.
Common Mistakes That Invalidate Hard Partitioning
Even well-intentioned implementations can fail Oracle's scrutiny. These are the most frequent errors that negate the licensing benefit of hard partitioning.
Using VMware as "Hard Partitioning"
No VMware configuration — CPU affinity, reservations, limits, DRS rules, or resource pools — is accepted by Oracle as hard partitioning. This is the single most common and most expensive audit finding. Enterprises running Oracle on VMware must licence every core in the VMware cluster, not just the cores assigned to Oracle VMs.
Uncapped IBM LPARs
An IBM LPAR configured in uncapped mode can dynamically borrow additional processing capacity from other LPARs. Oracle treats uncapped LPARs as soft partitioning — requiring licensing of the entire physical server, not just the LPAR. Always verify that Oracle-hosting LPARs are in capped mode with a hard maximum.
Temporary Cap Removal
Increasing a partition's CPU allocation — even briefly for performance troubleshooting — creates compliance exposure for the entire period the cap was removed. Oracle audits examine historical configurations, not just the current state. If logs show the LPAR ran at 16 cores for two weeks before being recapped at 8, Oracle will claim licensing was required for 16 cores during that period.
Additional pitfalls include: failing to pin CPUs on Oracle VM (configuring the VM without CPU affinity renders it soft-partitioned), allowing Oracle VMs to live-migrate to unpinned hosts, assuming memory or socket restrictions satisfy Oracle's requirements (only CPU core restrictions count), and neglecting to maintain documentation after the initial setup — a configuration change that invalidates compliance may go undetected until the next audit, potentially years later.
Demonstrating Compliance During an Oracle Audit
Oracle LMS will examine your partitioning configuration in detail during an audit. The burden of proof is on you — Oracle assumes full-server licensing unless you demonstrate otherwise.
🎯 Audit Evidence Checklist for Hard Partitioning
- Technology identification: Confirm the partitioning technology is on Oracle's approved list (with version number).
- Configuration screenshots: Management console views showing partition definitions, CPU allocations, and cap settings.
- Command-line evidence: Output from system commands (e.g.,
lparstat -i,virsh vcpupin,zonecfg info) confirming CPU boundaries. - Historical logs: Timestamped records showing the partition configuration has been consistent over the audit period. If changes occurred, document them with dates and reasons.
- Change management records: Evidence that partition modifications follow a controlled process with licensing impact assessment.
- Migration policy: For OVM/KVM environments, documentation showing that Oracle VMs are restricted from migrating to unpinned hosts.
- Performance monitoring: CPU utilisation data confirming Oracle never exceeded the partition boundary — reinforcing that the cap is effective, not theoretical.
- Licence allocation register: Mapping between each partition and the specific Oracle licences allocated to cover it.
Present this evidence proactively at the start of the audit engagement — before Oracle LMS draws its own conclusions. A well-organised compliance package that clearly demonstrates the partition boundaries, configuration integrity, and licence-to-partition mapping significantly reduces the likelihood of disputes and accelerates audit closure.
Maintaining Compliance Over Time
Hard partitioning is not a one-time configuration exercise. It requires ongoing governance to ensure the licensing benefit is preserved as infrastructure evolves.
Quarterly Configuration Audits
Schedule internal reviews every quarter to verify that all Oracle-related partitions remain correctly configured. Check for accidental cap changes, firmware updates that may have reset settings, and new servers added to the environment without proper partitioning. Treat each quarterly review as a mini audit rehearsal.
Integrate with Change Management
Require that any change to a server hosting an Oracle partition — hardware upgrades, firmware patches, virtualisation updates, or performance tuning — triggers a licensing impact assessment. If an operations team upgrades a server from 16 to 32 cores but the Oracle partition cap remains at 8, no licensing change is needed. But if the upgrade also reconfigures the partition, the licensing team must be notified.
Monitor Oracle's Policy Updates
Oracle periodically updates its partitioning policy document. While changes are infrequent, an update that removes or modifies the acceptance criteria for a technology you rely on could affect your compliance position. Subscribe to Oracle's policy notifications, monitor licensing advisory channels, and review any updates with independent advisers before your next audit.
Strategic Recommendations for CIOs
🎯 Hard Partitioning Implementation Checklist
- Verify the technology is on Oracle's approved list: Check the latest Oracle partitioning policy document for your specific technology and version.
- Configure hard caps, not soft limits: Every Oracle partition must have a fixed, immovable CPU core maximum that cannot be exceeded.
- Ensure persistence across reboots: Validate that partition settings survive restarts, firmware updates, and maintenance windows.
- Restrict VM mobility: Disable live migration for Oracle VMs or ensure identical pinning on all potential target hosts.
- Document continuously: Maintain timestamped configuration evidence — screenshots, command output, change logs — for every Oracle partition.
- Lock down admin access: Restrict partition modification rights to authorised personnel with change management approval.
- Never use VMware for Oracle sub-capacity: No VMware configuration is accepted. If Oracle runs on VMware, licence the entire cluster.
- Conduct quarterly internal audits: Verify configurations, check for drift, and update documentation every quarter.
- Integrate with change management: Require licensing impact assessment for any infrastructure change affecting Oracle partitions.
- Engage independent advisers for audit preparation: Pre-audit review by specialists ensures your evidence package meets Oracle LMS standards.