Where Oracle database licensing meets virtualization the stakes are well understood, but the same exposure sits quietly under WebLogic, Coherence, SOA Suite, and the rest of the Oracle middleware stack. Run any of it on a VMware cluster and the question Oracle asks is not how many cores the software uses. It is how many cores the software could reach. On a large shared cluster that distinction is the difference between a contained licensing position and a finding that runs into seven figures.
Does Oracle recognise VMware as hard partitioning for middleware?
Oracle does not recognise VMware as hard partitioning for middleware, exactly as it does not for the database. Oracle's partitioning policy treats VMware, Hyper V, and KVM as soft partitioning, which means it does not reduce the number of processors you must license. Under that policy Oracle can argue that every physical core in a cluster where the middleware can be powered on, migrated to, or failed over to is licensable, even if the software only ever runs on a fraction of them. The buyer move is to remember that the partitioning policy is a policy document, not your contract. Cluster wide claims rest on that policy, and contract language beats policy where the two diverge.
How is Oracle middleware counted on a virtual cluster?
Oracle middleware is counted on a virtual cluster by applying the processor metric to every host the software is licensed to run on, then multiplying physical cores by the core factor from the core factor table. The trap is scope. A vSphere cluster with vMotion enabled lets a virtual machine move across every host, so Oracle's position is that the whole cluster counts, not the two hosts where WebLogic actually sits. Where the estate is one large cluster shared across many workloads, the processor count Oracle proposes can be a multiple of the real footprint. Counting the deployment correctly starts with establishing where the software can genuinely run, which is a technical and contractual question, not an assumption.
| View | What is counted | Effect on the number |
|---|---|---|
| Where it runs | Two hosts hosting WebLogic | The real footprint |
| Oracle policy claim | Every host in the vMotion boundary | Often a large multiple |
| Contract position | What the signed agreement actually permits | Usually narrower than the policy |
What contains the exposure?
What contains the exposure is architecture and evidence together. Isolating Oracle middleware onto a dedicated cluster, or onto hosts pinned so the software cannot migrate across the wider estate, shrinks the boundary that Oracle can claim. Where that segregation already exists, the defense is to evidence it: host affinity rules, cluster boundaries, and the configuration that proves the software never had the run of the data centre. A preliminary finding will assume the broadest possible reach. An independent line by line review of that finding tests every host in the claim against what the contract permits and what the configuration shows, and that review typically cuts inflated claims by 60 to 80 percent.
What evidence proves the real footprint?
The evidence that proves the real footprint is configuration data, not assertion: the cluster definitions, the host affinity and anti affinity rules, the vMotion and DRS settings, and the deployment records that show where the middleware was installed and run. Oracle builds a finding from the broadest reading available to it, so the burden in practice falls on the buyer to demonstrate the boundary. Assembling that evidence file before any response is filed is what lets you meet a cluster wide claim with a documented, narrower count rather than a counter assertion. A claim answered with a recital of policy loses. A claim answered with the configuration that contradicts it holds.
Is running Oracle's collection scripts mandatory here?
Running Oracle's collection scripts is a decision, not an obligation, and on virtualized middleware it matters because those scripts can overcount across virtualization layers, attributing capacity to hosts the software never used. Script output should be reviewed before it is submitted, because once a number is handed over it anchors the negotiation. The buyer move is to understand what the scripts measure, reconcile their output against your own configuration evidence, and present a reconciled position rather than raw output that flatters the broadest possible claim.
For the mechanics of counting cores once the boundary is set, see counting middleware processors correctly. For how these claims surface in a live review, see WebLogic in an Oracle audit. The full method sits in the Oracle license compliance guide, and the workbook below turns it into a checklist you can run against your own estate.