Oracle Solaris Zones as Hard Partitioning: Capped vs Uncapped and What Oracle Accepts

Solaris Zones is one of a handful of technologies Oracle will accept as hard partitioning, but only in three specific configurations and only with evidence you can produce on demand. This page gives you the exact zonecfg settings that hold, the ones that quietly license the entire server, and the artifact set to keep so an auditor has nothing to argue with.

The Two Documents That Decide Your Count

Everything Oracle will claim about your Solaris estate traces back to two PDFs, and neither one is in your contract. The first is the Oracle Partitioning Policy (partitioning-070609.pdf), which lists Solaris Zones, also called Solaris Containers, among approved hard partitioning technologies with the parenthetical qualifier "capped Zones/Containers only". That parenthetical is the entire negotiation. The policy also states that all approved hard partitioning technologies must have a capped or maximum number of cores or processors for the given partition, which means an uncapped zone fails at the policy level before anyone opens a zonecfg file. The second document is the technical rulebook the policy points to by reference: "Hard Partitioning With Oracle Solaris Zones," An Oracle White Paper, October 2014 (os-zones-hard-partitioning-2347187.pdf). Note the date. In 2026 Oracle audits Solaris 11.4 estates against a paper written for Solaris 11.1-era behavior, and in 25 years of these arguments I have never seen an LMS reviewer volunteer that gap.

Now the leverage. The Partitioning Policy carries an effective date of February 14, 2022, and states on its own face that it provides guidelines regarding Oracle's policies in effect as of that date, may not be incorporated into any contract, does not constitute a contract or a commitment to any specific terms, and is subject to change without notice. Read that again as a buyer. Unless your OLSA, OMA, or a specific ordering document incorporates the policy by reference, it is Oracle's published administrative position, not a term you agreed to. Auditors apply it as though it were contractual, and most customers let them, which is precisely why the gap is worth preserving. Our wider Oracle soft partitioning audit defense guide covers how that distinction plays out across KVM and OCI as well.

The policy states on its own face that it may not be incorporated into any contract, yet auditors apply it as if you had signed it.

Do three things the day an audit notice lands. Download the live partitioning PDF from Oracle's site, screenshot the effective date line, and archive the file with a hash and a timestamp. Do the same for the October 2014 Zones white paper. Then pull your executed agreements and search for any reference to partitioning, hard partitioning, or the policy URL. If the reference is absent, you are negotiating against a document Oracle can revise unilaterally, and you should say so in writing before you hand over a single zonecfg export.

The Three Configurations Oracle Actually Accepts

The 2014 white paper presents what it calls the three types of approved resource management for hard partitions, and there are exactly three. Method one is dedicated-cpu, which specifies that a subset of the system's processors is dedicated to a non-global zone while it runs; the system dynamically creates a temporary pool at zone boot. Oracle permits an ncpus range here, and warns that where a range is used the maximum value must be used for licensing. Method two is capped-cpu, an absolute limit on CPU resources consumable by a zone. It carries a single ncpus property expressed as a positive decimal with two digits to the right of the decimal, corresponding to units of CPUs. It does not accept a range. A value of 1.00 means 100 percent of one CPU, 1.25 means 125 percent, and Oracle confirms in the white paper that the value need not be an integer and may include a fraction. Method three is resource pools: create a pool with a set number of CPUs and add one or more zones to that pool.

The sentence to keep in your back pocket is Oracle's own definition. The white paper states that the designation "capped" is a generic way of stating the zone has a defined upper CPU boundary which is less than all the CPUs on the system, and that the term refers to all valid methods of configuring Oracle Solaris Zones. When an auditor argues that only capped-cpu qualifies because the policy says "capped Zones," quote that line back verbatim. Equally, note the second half of it: a boundary set equal to the box's total thread count is not a partition, it is full-server licensing with extra configuration steps. Compare your production configs line by line against the syntax below, and cross-check the results against the broader method comparison in our practical guide to Oracle-approved hard partitioning.

Two practical notes. Fractional capping under capped-cpu is a genuine cost lever that almost nobody uses; a 3.50 cap on a heavily threaded SPARC box can materially reduce the licensable count where workload profiling supports it. And avoid ranges under dedicated-cpu unless you have a documented operational reason, because a range plus a running poold daemon reads to an auditor as an elastic partition, and you will spend the meeting defending intent rather than arithmetic. Fixed integers, or fixed decimals, are what hold.

Uncapped Zones: Why the Whole Server Lands on the Invoice

The policy language does the damage before anyone opens a zonecfg file. Oracle's Partitioning Policy requires that all approved hard partitioning technologies have a capped or maximum number of cores or processors for the given partition, and it names Solaris Zones with the parenthetical "capped Zones/Containers only." An uncapped zone has no maximum by definition, so it fails that test at the policy level. The consequence is not a smaller discount or a partial credit: anything not listed in the Hard Partitioning section is treated as soft partitioning, which requires licenses for all physical processors on which the Oracle software is installed and/or running. Practically, that means every core in every socket in the chassis, multiplied by the applicable core factor, whether the zone was using two threads or two hundred. The trap is mechanical rather than malicious. Zones get built uncapped by default during provisioning, P2V migrations, and DR rebuilds, and nobody re-runs the check after a hardware refresh doubles the socket count or a zone is live-migrated onto a bigger frame. In our audit work the failure is almost never the original design; it is the third or fourth change nobody documented. Note also that a "cap" set equal to the box's total thread count is not a partition at all, because Oracle's own white paper defines the capped designation as a defined upper CPU boundary which is less than all the CPUs on the system. That configuration buys you full-server licensing with extra administrative steps and a false sense of coverage.

The multiplier in that table is 8x on the same running workload, and it is driven entirely by a configuration line, not by consumption. Options compound it, because every Enterprise Edition Option is licensed on the same processor count as the database itself, so RAC, Multitenant, and the management packs all scale with the uncapped number. Before you accept any auditor position on an uncapped zone, read the contest angles in our Oracle soft partitioning audit defense guide, then remediate forward rather than arguing history.

An uncapped zone has no maximum by definition, so it fails Oracle's own capping test before anyone opens a configuration file.

The ncpus Range Trap and the poold Problem

The dedicated-cpu resource accepts a range for ncpus, and Oracle's October 2014 white paper states plainly that where a range is used, the maximum value must be used for licensing purposes. So set ncpus=1-3 licenses at 3, not at 1, and not at whatever the utilization graphs show. That alone converts a well-intentioned elasticity setting into a 200 percent uplift on the license count for that zone. The second-order risk is worse, because specifying a range pulls the importance property into scope. Importance defines the relative priority of the pool, matters only when poold is running to manage dynamic resource pools, is ignored when poold is not running, and defaults to 1 when poold is running and the value is unset. An auditor who sees a range in the configuration plus a live poold process reads an elastic partition rather than a fixed boundary, and that reading gives them an argument that no cap was ever enforced at all. You then spend the audit defending intent instead of producing evidence, which is the weakest ground available.

The instruction is unambiguous. Replace every range with a fixed integer, or move the zone to capped-cpu, which does not accept a range and does accept a decimal such as 3.5 if you want a fractional boundary. Confirm poold status on every frame hosting Oracle workloads and record the result with a timestamp. Treat any surviving range as an uplift you have already conceded, and price it at the maximum when you build your own position, because Oracle will. If you are standardizing configurations across a mixed estate, align the Solaris settings with the same discipline described in our practical guide to Oracle approved hard partitioning, so one platform does not undermine the evidence set for the others.

Misconfigurations That Void the Partition

The fastest way to lose a Solaris hard partition is to combine controls Oracle documents as mutually exclusive. capped-cpu and dedicated-cpu cannot coexist on the same zone: dedicated-cpu builds a temporary pset for the zone at boot, capped-cpu applies an absolute ceiling to whatever CPU the zone can see, and stacking them produces a configuration Solaris will reject or resolve in ways you cannot evidence. Likewise, the cpu-shares rctl is incompatible with dedicated-cpu, because shares operate inside the fair share scheduler on a pool the zone no longer draws from. That second point matters more than the syntax error, because cpu-shares is the single most common misplaced defense we see in Solaris estates. FSS shares are a scheduling weight, not a ceiling. A zone with 100 shares on an idle box consumes every thread available to it. Nothing in Oracle's approved list contemplates shares, and the policy's own universal rule requires a capped or maximum number of cores for the partition, so a shares-based zone licenses the full server. If your architecture team has been telling procurement that the zones are "constrained," ask specifically whether the constraint is capped-cpu, dedicated-cpu, or a fixed pset, and treat any other answer as an unlicensed exposure.

Oracle's own documentation flags the second trap, and auditors know it. Applications that auto-size to available CPUs, including the Oracle database and JVMs, may not recognize a capped-cpu restriction, so CPU_COUNT can report the full physical thread count while the cap sits at 3.5. That mismatch is a thread auditors pull hard on, because it lets them argue the software had visibility beyond the boundary. Set CPU_COUNT explicitly to match the cap, document the parameter file, and be ready to explain why the values differ if you inherited a legacy instance. Our wider guidance on implementing Oracle approved hard partitioning covers the same reconciliation discipline across platforms.

The Evidence Set an Auditor Cannot Argue With

A valid configuration you cannot prove is worth nothing in an audit. The artifact set is short and specific: zonecfg -z zone info and zonecfg -z zone export for every non-global zone running Oracle software, poolcfg -dc info and poolstat output showing pset membership and CPU counts, the persistent CPU, core, and socket binding properties where your Solaris release supports them, zoneadm list -cv to prove which zones existed and in what state, and dated change records tying every configuration change to a numbered ticket. Point-in-time output is weak. Oracle's contractual look-back is typically the full license term, and an auditor's implicit question is not "is this capped today" but "was it capped in Q3 of 2023 when that instance was running." Continuity is what wins. Capture monthly snapshots into an immutable store, WORM object storage or a signed archive, covering the entire look-back period, and keep CPU_COUNT settings and init parameter files alongside them so the database view reconciles to the cap without a conversation.

Expect Oracle to ask you to run its scripts and hand over server-level data that reaches well past the zones in scope. What you run and what you hand over is a negotiation, not an obligation. Most audit clauses give Oracle a right to reasonable cooperation, not a right to arbitrary tooling on your production estate. Offer your own artifact set first, in the format above, and require a written scope statement naming the servers and the period. If Oracle insists the data is incomplete, make it identify the specific gap. That posture, combined with the point that the partitioning policy is not contractual unless referenced into your agreement, is the same leverage described in our Oracle soft partitioning audit defense guide. In our negotiation experience, buyers who arrive with 24 to 36 months of dated snapshots close partitioning disputes without a purchase.

A valid configuration you cannot prove is worth nothing in an audit.

What to Do First

Treat this as a 72-hour discovery exercise followed by a 30-day remediation window, because the arithmetic gap between a capped count and a full-server count is the only number that matters once an auditor is on the call. In the first 72 hours, run zonecfg -z info against every zone that has ever hosted Oracle binaries, not just the ones you think are licensed, and flag three conditions: no dedicated-cpu, capped-cpu, or fixed pset at all (uncapped), an ncpus range rather than a fixed integer, and any cap set equal to the box's total thread count. Then quantify. Multiply the full socket and core count of each host by the Oracle core factor and the list or contracted price for every product on that zone, and compare it to what you currently hold. That delta, per host, is your exposure, and you want it in a spreadsheet before Oracle produces its own version.

• Within 30 days, convert ranges to fixed integers, remove uncapped zones from Oracle scope or cap them, and capture dated before-and-after configuration output as your remediation record. See the hard partitioning implementation guide for the sequencing.
• Archive the Partitioning Policy PDF and the October 2014 Solaris Zones white paper at their current effective dates, with checksums. In our experience, disputes turn on which version was live when the configuration was built.
• Extend the same inventory logic to adjacent platforms using the KVM and OLVM core count analysis, since mixed estates are where findings cluster.

Hold the posture line: the Partitioning Policy is not a contract term unless your agreement references it. If an audit finding treats it as binding, contest that assumption first, before you argue configuration details, because everything downstream inherits it.

Related advisory: the full topic guide.

Frequently asked questions

Does an uncapped Solaris Zone reduce my Oracle license count at all?

No. Oracle's Partitioning Policy requires every approved hard partitioning technology to have a capped or maximum number of cores or processors, and an uncapped zone has no maximum. In an audit Oracle will treat the configuration as soft partitioning and count every physical processor in the server that the Oracle software could run on, including the non-global zone's full host. The zone boundary buys you operational isolation, not a licensing reduction.

Can I use a fractional CPU cap such as 2.5 for licensing purposes?

Yes for the configuration, with the usual rounding applied to the license calculation. Oracle's white paper states that the ncpus value for capped-cpu does not have to be an integer and may include a fraction of a CPU, and that following this method creates a valid hard partition environment. Round the resulting core count up when you compute Processor licenses and apply the relevant core factor. Keep the zonecfg output that shows the fractional cap, because it is unusual enough that an auditor will question it.

Does cpu-shares or Fair Share Scheduler count as capping the zone?

No. cpu-shares is a scheduling weight that governs relative access under contention, not a ceiling on how many CPUs the zone can consume. Oracle documents that cpu-shares is incompatible with dedicated-cpu, and it appears nowhere among the three approved methods. If your Solaris estate relies on FSS shares as its licensing defense, treat that as an open exposure and remediate to dedicated-cpu, capped-cpu, or a fixed resource pool.

Is the Oracle Partitioning Policy binding on me?

Only if your license agreement, ordering document, or an amendment references it. The document says on its own face that it may not be incorporated into any contract, does not constitute a contract or commitment to specific terms, and is subject to change without notice. Oracle nonetheless applies it in every audit, so plan to comply technically while reserving the contractual argument. Check your OLSA or OMA for any incorporation-by-reference language before you concede a finding built on the policy.

What evidence does Oracle expect for a capped zone at audit?

At minimum, zonecfg info and export output for every zone running Oracle software, poolcfg and poolstat output where resource pools are used, and evidence that the configuration was continuous across the audited period rather than set up the week the notice arrived. Persistent CPU, core, or socket binding properties in modern Solaris releases are the strongest form because they survive reboot. Add dated change records and monthly snapshots stored where they cannot be edited.

If my cap equals the total thread count of the server, is that still a hard partition?

No. Oracle's own language requires the defined upper CPU boundary to be less than all the CPUs on the system. A cap set at the box total is functionally full-server licensing with additional configuration overhead, and it gives you nothing to argue at audit. Set the cap at the level the workload actually needs, document the headroom decision, and revisit it after any hardware refresh that changes the denominator.