In a VMware estate the certified number is only as strong as the evidence behind each cluster. The Cluster Documentation Pack is the per cluster record that proves which processors belong in your Oracle ULA count and which do not, built before the certification window rather than scrambled during it.
Certifying an Oracle ULA in a virtualized estate is a documentation problem before it is a counting problem. Oracle's partitioning stance treats VMware as soft partitioning, which means the platform itself will not limit the scope of your count. What limits it, or widens it when widening serves you, is the evidence you can show for each cluster. The Cluster Documentation Pack is our name for that evidence, organised so every processor in your certified number traces back to a record that holds. This article sets out what the pack contains, what each item proves, and why it has to be assembled while the estate is stable rather than reconstructed under time pressure.
Oracle does not publish a required cluster evidence list, so the standard is practical rather than prescribed. A defensible pack records five things for each cluster: the cluster boundary and what is inside it, the hosts and their physical cores, where Oracle virtual machines run and where they could move, the isolation controls that constrain that movement, and the dates that show the configuration held through the relevant period. Recorded together, these let you state the processor count for the cluster and answer the obvious follow up question, which is how you know the count is not larger.
No, not on its own. Under Oracle's partitioning stance soft partitioning does not limit scope, so the technology will not shrink your count and the documentation has to do that work instead. Where your contract allows a narrow reading, dedicated clusters and configured isolation supported by dated evidence are what make the narrow count credible. Where a broad count serves you, the same discipline lets you claim the full cluster with confidence. The pack is neutral on direction. It exists to make whichever count your contract supports defensible, and the contract is where the boundary really sits. The underlying contract language is covered in the virtualization clauses in your ULA, and the count behaviour those clauses produce is covered in VMware and Oracle ULA certification.
Each cluster gets its own pack. The items below are the minimum that lets a reviewer trace your number without taking anything on trust.
A plain description of the cluster as the virtualization platform defines it: the cluster name, its purpose, and the hosts that belong to it. This is the unit the count is built on, so ambiguity here undermines everything downstream. If two clusters share storage or a management domain, say so and explain why that does not extend the scope. The boundary statement is the sentence the rest of the pack supports.
For every host in the cluster, the make and model, the processor type, the socket and physical core count, and the Oracle core factor that applies to that processor. This is the arithmetic floor of the count. A processor count is physical cores multiplied by the core factor, so an inventory that is wrong on cores or core factor is wrong on the number. Pull this from the platform and from hardware records, and reconcile the two rather than trusting either alone.
Where Oracle virtual machines actually run, and where the cluster configuration would allow them to move. This is the heart of a VMware count. A reviewer reading the broad position will ask whether an Oracle workload could migrate to a host you have left out of the number. The placement record answers that question with configuration rather than assertion. If host affinity rules or migration boundaries keep Oracle on a defined set of hosts, those rules belong here, exported from the platform and dated.
The specific settings that keep the cluster boundary real: affinity and anti affinity rules, separate management domains, storage separation, and any administrative controls that prevent an operator from quietly moving Oracle outside the documented set. Isolation is the defense that turns a soft partitioning platform into a hard boundary in practice. Without the controls the boundary is a hope. With them it is a configuration you can show. The defensive use of dedicated hosts is set out in dedicated clusters as a defense.
Configuration exports, screenshots, and tool output carrying dates that show the state held across the period that matters, not just on the day you ran the report. A single snapshot proves a moment. A trail proves a régime. Where the contract counts what was deployed within the term, the dates are what tie a configuration to the term. Keep the raw exports, not only a summary, because the summary is your interpretation and the export is the fact.
A short written explanation that ties the four data items together into the count claimed for the cluster, and names any assumption a reviewer would otherwise have to guess. This is where you state, in your own words, why the count is the number it is. It is also where you flag any point that depends on the contract reading, because in ULA work the count almost always depends on the wording of your own agreement.
Consider an indicative cluster of four identical hosts, each with two sockets of sixteen physical cores, running on a processor type that carries a core factor of 0.5. The host and core inventory gives 4 hosts multiplied by 32 cores, which is 128 physical cores, multiplied by 0.5, for 64 processors. The placement record shows Oracle confined to two of the four hosts by affinity rules, and the isolation controls show those rules enforced and administratively locked across the term. Where the contract supports a count tied to where Oracle can run rather than where the cluster could theoretically place it, the supportable number is 64 processors for the two locked hosts, not 128 across all four. The figures are indicative and the count any real cluster supports turns on your contract language.
The certification window is the wrong time to discover your evidence does not exist. By then the estate is whatever it is, and reconstructing a year of configuration history from memory is neither convincing nor quick. Built 12 to 18 months out, the pack does three things the late version cannot. It tells you the count you can actually support before you commit to it, so there are no surprises in the letter. It lets you change the estate deliberately while there is still time, isolating Oracle to narrow the count or deploying across clusters to widen it, depending on which the contract and your interests favour. And it gives you a contemporaneous record rather than a back dated one, which is worth far more if Oracle reviews the certification later. Audit risk rises in the two years after certification, and the evidence file is the defense. The timing logic for the wider exit is set out in our ULA exit strategy guide.
The Cluster Documentation Pack is the virtualized portion of a larger evidence file. The same discipline applies to physical servers, to cloud deployments where the contract lets them count, and to the methodology note that explains your counting approach as a whole. The cluster packs slot into that file as the part that handles VMware, which is usually the part Oracle examines most closely because it is where the soft partitioning argument lives. Keeping the cluster evidence clean keeps the whole file clean, and a clean file is what lets a certified number stand without a fight.
If you hold an Oracle ULA with a meaningful VMware footprint, the cluster documentation is not optional and it is not something to start in the final quarter. Begin with the contract, because the count your packs can support is set by the virtualization clauses in your ULA, then build the packs against the estate you have, then decide whether to reshape that estate while time allows. For the full exit framework the packs sit inside, our ULA exit strategy guide is the place to start, and to see how the count behaves once the evidence is in hand, read VMware and Oracle ULA certification. Because the supportable count turns entirely on your own wording and your own configuration, the surest way to know your real position is to have both read together early.
Oracle has no fixed list, but a defensible position records the cluster boundary, the hosts and their cores, where Oracle virtual machines run and could move, the isolation controls in place, and the dates that show the state held through the term. Together these prove which processors belong in the count.
Under Oracle's partitioning stance soft partitioning does not limit scope, so the documentation has to do the work that the technology will not. Dedicated clusters, configured isolation, and dated evidence support a narrow count where the contract allows it, while silence and sprawl support a broad one.
We assemble the cluster documentation that makes your VMware count hold, and tell you the number your contract actually supports.