ALA virtualization and partitioning rules

Virtualization changed how software runs, but the rules for counting it lag behind. A product licensed by capacity now commonly runs inside a virtual machine on a partition of a far larger physical host, and the question of what to count, the partition or the host, is where many findings inflate. ALA virtualization and partitioning rules are the terms in an Additional License Authorization that govern how capacity is measured when the software runs on virtualised or partitioned infrastructure. A finding that counts the entire physical host when the deployment is confined to a defined partition can multiply the obligation many times over.

This field note explains how virtualised deployments are counted, where the host versus partition question goes wrong, and how the defensible reading holds the count to the capacity actually made available to the software. It pairs with our ALA and entitlement review track.

The host versus partition question

The central issue is simple to state and consequential to resolve. A capacity metric counts machine resources, and when software runs in a virtualised environment, the resources available to it may be only a fraction of the physical host. A deployment confined to a partition with a defined allocation of cores uses that allocation, not the full host. A finding that counts the physical host as though the software could use all of it, regardless of the partition boundary, measures capacity the software was never able to consume. The correct count follows the capacity actually made available, and that depends on how the authorization defines the unit, a subject we treat in capacity definitions in Micro Focus ALAs.

Hard partitioning versus soft partitioning

Findings frequently turn on the distinction between partitioning methods. Some virtualization technologies enforce a fixed boundary that the software cannot cross, while others allocate resources in a way an auditor may argue is changeable. A finding will tend to treat a soft boundary as no boundary at all, counting the full host on the theory that the allocation could in principle expand. The defensible reading establishes what the partition actually permitted during the relevant period and counts against that, rather than against a hypothetical maximum the deployment never used. The argument is about what was, not what could conceivably have been, and the evidence is the configuration record.

Where the count inflates

Virtualised capacity counts inflate in a predictable pattern. The auditor counts the physical cores of the host rather than the cores allocated to the partition. Or the auditor sums capacity across hosts in a cluster on the theory that the workload could migrate, counting standby capacity as if it were active. Or the auditor ignores a partition boundary because the authorization's virtualization language is read narrowly against the buyer. Each of these substitutes a larger figure for the capacity the software actually had, and each can be answered by reading the virtualization rules in the authorization together with the configuration the buyer can document. Migration and standby scenarios overlap with the rights examined in ALA disaster recovery and standby rights.

Evidence is the configuration record

Virtualization disputes are won on configuration evidence. The partition allocation, the virtualization platform, the core assignment, and the period each was in force are all matters the buyer can document, and a finding that counts the host can be answered with the record that shows the partition. The cleaner the configuration evidence, the faster the overreach is corrected, because the question of what the software could use is settled by the record rather than by argument. This is the same documentary discipline we apply across entitlement defense, set out in documenting ALA entitlements for a rebuttal.

How we defend the virtualized count

Our defense reads the virtualization and partitioning rules in the authorization that governed each purchase, then tests the finding against the capacity the software actually had. We establish the partition boundaries, the core allocations, and the periods they were in force, and we show where the finding counted the physical host, summed a cluster, or ignored a partition that confined the deployment. Where the count exceeds the capacity made available to the software, it is corrected to the boundary the configuration enforced. This is the Reconstruct and Rebut work of our method, and holding a capacity count to what the software could actually consume is the same discipline that moved our E-03 case file, a finding driven by overcounted capacity and connectors, from $6.0M to $1.8M, a 70 percent reduction.

Clusters and live migration multiply the overreach

The most aggressive virtualized counts arise in clustered environments. Where a workload can in principle move between hosts in a cluster, an auditor may count every host the software could conceivably run on, summing the capacity of the entire cluster as though the deployment occupied all of it at once. This treats a possibility as a fact and a standby host as an active one, and it can multiply the count by the number of nodes in the cluster. The defensible reading establishes where the software actually ran during the relevant period and what capacity it actually consumed, rather than the theoretical maximum the cluster could have offered. Live migration is a capability, not a deployment, and a finding that prices the capability as if it were continuous, simultaneous use across every node has counted capacity the software never touched.

Closing the virtualization question forward

Once the present finding has been corrected, the forward agreement should state the virtualization and partitioning terms plainly, so a future review cannot reopen the count by reaching for the full host. A clean forward arrangement records how capacity is measured under virtualization, what partition boundaries count, and how migration and standby are treated, removing the ambiguity that let the audit overreach. Resolving the finding and fixing the virtualization rules forward are two halves of the same work. If a finding has counted your physical host when the deployment was confined to a partition, open a case and we will hold the count to the capacity the software actually had.

For the full method, read the complete OpenText audit defense playbook, and for entitlement defense across the Micro Focus estate see our ALA and entitlement review track.