Solaris zones and IBM PVU counting.
Oracle Solaris zones are eligible virtualization technology for IBM sub-capacity, but the PVU count turns entirely on whether a zone is capped. Get the cap and the tooling right and you license the cores the zone can use. Get them wrong and IBM counts the whole physical server.
Solaris remains common in long lived enterprise estates, and IBM middleware running inside Solaris zones is a recurring audit topic precisely because the configuration detail that decides the number is invisible day to day. Two zones that look identical in an inventory can carry very different PVU positions depending on how each one was bound to processors. Under audit, that detail is the difference between a sub-capacity number and a full server charge.
Capped versus uncapped is the whole question
IBM sub-capacity counts the processor cores a zone is entitled to use. A capped zone, bound to a defined set of cores or a processor cap, lets you license only those cores for the IBM software it runs. An uncapped zone that can draw on the full processor resource of the host is counted at the host's full capacity, because nothing limits what it could consume. The software does not behave differently. The licensing does.
The cap has to be the kind IBM recognizes
Not every form of resource control qualifies. IBM recognizes specific capping mechanisms for sub-capacity counting, and an informal or soft limit that does not hard cap the processors available to the zone will not reduce the count. The configuration must constrain the zone in a way the rules accept, and that configuration has to be evidenced, not merely asserted.
An IBM product in a zone capped to 4 cores on a 32 core Solaris host is 480 PVU under sub-capacity. The same product in an uncapped zone on that host, free to use all 32 cores, is 3,840 PVU at full-capacity. The deployment is identical. Only the cap, and the evidence of it, separates the two numbers.
The conditions that have to hold together
- The zone is hard capped by a mechanism IBM recognizes, with the configuration documented for the audit period.
- The Solaris release and zone technology sit within IBM's eligible technology list.
- The IBM License Metric Tool, or an approved alternative, is deployed within 90 days, runs continuously, and captures the zone correctly.
- Quarterly sub-capacity reports are generated and retained for two years.
- The in-scope product is itself sub-capacity eligible, independent of the platform.
Most Solaris findings we see come down to one of two things: a zone that was capped in practice but not in a form the evidence could prove, or an inventory tool that recorded the host rather than the zone. Both are defensible with the right configuration history, but both default to full-capacity if that history cannot be produced when the auditor asks.
On Solaris, sub-capacity lives or dies on the cap. Confirm each zone is hard capped by a recognized mechanism, that the tooling recorded the zone and not just the host, and that the configuration is evidenced for the whole period. Establish it before the data leaves your network, or IBM counts every core on the server.