What IBM auditors look for in server inventory data.

Cores, hosts and the capacity question

The first thing an auditor reads is capacity. How many physical cores sit under each host, how many are allocated to the IBM software, and whether the deployment qualifies for sub capacity at all. With PVU as a core based metric, every unresolved core is potential PVU, and an Intel core near 70 PVU adds up quickly across an estate.

Where the host topology is unclear, the auditor defaults to the reading that counts the most cores. Clean data answers the capacity question before they can.

Virtualization layer and eligibility

Next is the hypervisor. Each virtualization technology has its own rule. LPAR and Power count allocated cores even when idle, while VMware, the Microsoft hypervisor and cloud platforms each define eligibility differently. Running on ineligible technology, such as an unsupported server version, voids sub capacity entirely and exposes the full host.

Auditors look specifically for deployments where the virtualization story does not hold, because that is where full capacity charging is easiest to assert.

The ambiguities they resolve in their favor

• Decommissioned hosts still listed in a raw export, counted as live.
• Test and non production copies with no clear label, counted as production.
• Miscategorized installs from an uncorrected ILMT feed, counted as chargeable.
• Unmapped clusters where one container deployment can pull every core in the cluster into scope.

Sending a position, not an export

The lesson is that raw discovery output is not neutral, it is a set of ambiguities waiting to be read against you. Before inventory data leaves your network it should be scoped, labeled and reconciled, so each core, host and copy already carries its answer. That is the Contain step, and it is what turns an inventory file into a defensible position.