Virtualization is one of the richest sources of inflation in an OpenText or Micro Focus finding, because the gap between the cores a workload actually uses and the cores a measurement can be made to count is enormous. A product running in a virtual machine on a large cluster can be assessed against the whole physical host, or even the whole cluster, rather than the cores assigned to it. On core based and capacity based metrics this turns a modest deployment into a vast claim. OpenPass virtualization and partitioning terms are the contract language that fixes how cores are counted on virtual and partitioned infrastructure, and getting that language right is the difference between licensing the workload and licensing the data centre.
The principle is simple to state and frequently absent from the agreement: the buyer should license the capacity it allocates to the software, not the capacity that happens to exist on the hardware underneath it. Without that principle written down, the vendor is free to count the larger number.
Why virtualization inflates a core count
Core, capacity, and workload metrics were designed for physical servers, where the cores a product can use are the cores in the box. Virtualization breaks that assumption. A virtual machine assigned four cores may sit on a host with sixty four, inside a cluster of many hosts, with the ability to migrate live across the cluster. A measurement that ignores the virtual boundary and counts the physical host, or the cluster the machine could move to, produces a number many times larger than the workload. This is the same family of trap that appears across core and MIPS based products, examined for the mainframe estate in our COBOL and Enterprise Server audit defense track.
License the capacity you allocate to the software, not the capacity that happens to exist on the hardware beneath it. Without that principle in writing, the vendor counts the host or the cluster, not the workload.
Soft partitioning versus hard partitioning
The central distinction the agreement must address is between soft and hard partitioning. Hard partitioning physically or firmly constrains the cores available to a workload, and a buyer should be entitled to license only those constrained cores. Soft partitioning, where allocation is managed in software and could in principle be changed, is frequently treated by vendors as no constraint at all, on the argument that the workload could expand to the full host. The agreement should state which partitioning technologies are recognised as limiting licensable capacity and on what evidence, so that a legitimately constrained deployment is licensed at its real size. Leaving this undefined hands the vendor the right to ignore the partition entirely.
Live migration and the cluster question
Modern virtualization allows a workload to migrate live across the hosts in a cluster, and vendors use this mobility to argue that every host the workload could reach must be licensed, not just the host it runs on. This is the single most expensive virtualization position a buyer can face. The agreement should define licensable capacity by where the software actually runs, optionally constrained by affinity rules or host pinning that limit migration, rather than by the theoretical reach of the cluster. The way such forward exposure is contained in the agreement is examined in can OpenPass cap future audit exposure, and the broader discipline of pinning every metric down appears in defined metrics in an OpenPass enterprise agreement.
Cloud capacity and the same principle
Public cloud raises the virtualization question in a different form. Capacity is elastic, instances scale, and the underlying host is invisible to the buyer. The agreement should define cloud capacity by the virtual resources the buyer provisions to the software, the named instance types and core counts, rather than by any underlying physical infrastructure the buyer neither sees nor controls. Keeping the counting principle consistent across cloud, on premise, and virtualised environments prevents the same workload from being measured three different ways. The way deployment rights are written across these environments is set out in OpenPass cloud and on premise deployment rights.
Non production virtual environments
Virtualization and non production scope intersect directly, because test, development, and disaster recovery environments are overwhelmingly virtual. A virtual test rig counted at full production core value, on the full host, compounds two traps at once. The agreement should ensure that the virtualization counting rules and the non production definitions work together, so a virtual development environment is licensed as both non production and as its allocated cores. The non production boundary is examined in OpenPass development versus production scope. Where these two definitions are aligned, the support environments that are necessarily virtual stop being a source of exposure.
How this works in practice
In a recent engagement, a buyer faced a finding in which a core based product running on a handful of allocated cores had been assessed against the full physical hosts of a large virtual cluster, with the migration argument applied so that every host in the cluster was counted. The result was a claim many times the size of the actual deployment. The defense reconstructed the real allocation, evidenced the partitioning that constrained the workload, and demonstrated the affinity rules that limited migration. The finding was reassessed against the cores the software actually used, and the agreement was then redrafted so that virtual and partitioned capacity would be counted by allocation rather than by host for the remainder of the term. The reduction came from counting the workload, not the data centre. The reconstruction method runs through the complete OpenText audit defense playbook, and comparable outcomes appear across our engagements.
Counting the workload, not the hardware
OpenPass virtualization and partitioning terms come down to one principle written into the agreement: license what the software is allocated, not what the hardware can theoretically provide. Define which partitioning constrains capacity, fix licensable cores by where the workload runs rather than where it could migrate, keep the counting consistent across cloud and on premise, and align it with the non production rules. This work sits inside our OpenPass enterprise agreement negotiation track. If a core based or capacity based product in your estate runs on virtual or partitioned infrastructure, open a case before a measurement counts the whole cluster.
If an OpenText or Micro Focus audit notice has reached you, the first seven days weigh more than any week that comes after. OpenText Audit Defense is an independent, buyer side practice founded in 2020 by former vendor compliance leadership. Over more than 200 defended audits we have lowered the average finding by 68 percent and mitigated more than $90M in claims against vendor positions. We do not resell OpenText software and we are not affiliated with OpenText Corporation. To open a case, use the contact form on this site.