- Why Virtualisation Creates Audit Risk
- Oracle on VMware: The Highest-Risk Scenario
- IBM Sub-Capacity Licensing Requirements
- Microsoft Licensing in Virtual Environments
- Container and Kubernetes Licensing Risk
- Cloud Virtualisation and Licensing Complexity
- Mitigation: Building a Defensible Virtual Licence Position
Why Virtualisation Creates Audit Risk
Enterprise software licence agreements were largely developed in an era of physical server deployment where the relationship between software and hardware was direct and measurable. Virtualisation decoupled software from hardware, and vendors responded by updating their licensing policies — often in ways that were not transparently communicated to customers and that systematically increased licence requirements relative to what enterprises expected.
The fundamental dynamic is that virtualisation makes software portable across infrastructure. Oracle's VMware policy, IBM's sub-capacity rules, and Microsoft's virtualisation licence rights all reflect the same underlying vendor concern: that virtualisation enables enterprises to run more software on more infrastructure than was licensed. The audit programmes that follow exploit the gap between what enterprises believe they owe (based on what they intentionally deployed) and what vendors count (based on what the infrastructure could support).
"In virtualised environments, the gap between what enterprises believe they've licensed and what vendors claim in an audit is not a compliance problem — it is a documentation and contractual interpretation problem. The licence position is frequently defensible. The question is whether the enterprise has the evidence to defend it."
Oracle on VMware: The Highest-Risk Scenario
Oracle's VMware licensing policy is the most commercially aggressive virtualisation policy in the enterprise software market, and the most frequently litigated. Oracle's stated position is that VMware constitutes "soft partitioning" — and therefore enterprises running Oracle Database on VMware are required to licence all physical processor cores on every host in the VMware cluster where Oracle software runs (or could be vMotioned to run).
The practical impact is extreme. An enterprise running a single Oracle Database VM on a 20-host VMware cluster with 2 processors per host and 20 cores per processor faces an Oracle requirement to licence 800 processor cores at the applicable core factor. Where enterprises believe they need 20–40 licensed cores (based on the VM's vCPU allocation), Oracle calculates a requirement for 800 cores — a 20–40× overstatement relative to expectation.
Hard Partitioning as a Mitigation Strategy
Oracle permits sub-cluster licensing only when "hard partitioning" technology is used. Oracle's own Oracle VM (OVM) and Oracle Solaris Containers are explicitly listed as approved hard partitioning technologies. Hardware partitioning (Oracle SPARC hard domains, HP nPars, IBM LPARs) is also approved. VMware, Hyper-V, KVM, and virtually all other hypervisors are explicitly classified as soft partitioning and therefore do not permit sub-cluster licensing.
Enterprises that are committed to VMware infrastructure should understand that the only reliable Oracle VMware risk mitigation strategies are: isolating Oracle workloads onto dedicated VMware hosts that are licenced at full physical capacity; migrating Oracle workloads to Oracle Cloud Infrastructure (OCI) where Oracle permits OCPU-based licensing; or migrating to Oracle VM or alternative approved hard partitioning technologies.
Contractual Challenge Opportunities
Oracle's VMware policy has been updated multiple times and is not consistently reflected in all Oracle licence agreements, particularly those signed before 2010. Enterprises with older Oracle agreements should have legal counsel review whether the contractual language actually incorporates Oracle's current VMware policy. Several enterprises have successfully argued — through litigation and negotiated settlement — that Oracle's policy documents do not constitute binding contractual terms. See our complete guide to Oracle partitioning rules for the contractual analysis.
VMware Cluster Full Licensing
All physical cores on all VMware hosts in the cluster must be licensed. vMotion capability means any host is a potential Oracle host.
Sub-Capacity ILMT Compliance
Sub-capacity pricing requires ILMT running every 90 days. Non-compliance triggers retroactive full-capacity pricing for the entire audit period.
Windows Server VM Licensing
Windows Server Standard covers 2 VMs per licence. Licensing drift occurs as VMs proliferate and licence tracking fails to keep pace with deployments.
Digital Access in Virtualised Environments
Automated processes in virtualised or containerised environments that read SAP data via APIs may trigger digital access licence requirements.
IBM Sub-Capacity Licensing Requirements
IBM's sub-capacity licensing programme allows enterprises running IBM software on virtualised infrastructure to licence only the virtual processor cores (VPCs) assigned to their VMs rather than the full physical server capacity. This is a significant financial benefit — full-capacity IBM licensing on modern multi-core servers would be prohibitively expensive for most enterprises. However, sub-capacity eligibility requires continuous compliance with IBM's Licence Metric Tool (ILMT) deployment requirements.
The ILMT compliance requirements are: ILMT must be installed and configured to monitor all eligible virtualised IBM workloads; ILMT compliance reports must be generated and retained at minimum every 90 days; the ILMT database must not have gaps in monitoring data greater than the 90-day reporting frequency; and ILMT scan configurations must cover all VMs running IBM software, including any acquired through mergers or newly provisioned environments.
Enterprises that claim sub-capacity pricing but fail to maintain ILMT in compliance are contractually required to retroactively pay full-capacity pricing for the entire audit look-back period — typically the full term since the last demonstrated ILMT compliance. On large IBM estates, the retroactive pricing difference can run to millions of dollars. The IBM ILMT compliance audit guide explains the configuration and reporting requirements in detail.
Microsoft Licensing in Virtual Environments
Microsoft's virtualisation licensing is substantially less punitive than Oracle's but still creates material audit exposure in large, dynamically managed virtualised environments. The key licensing rules for Microsoft in virtualised environments cover Windows Server, SQL Server, and Microsoft 365 workloads.
Windows Server Virtualisation Rights
Windows Server Datacenter licences (applied per physical host) permit unlimited Windows Server VM instances on that host. Windows Server Standard licences (applied per physical core) permit two Windows Server VM instances. In environments where VM counts per host exceed Standard licence allocations, enterprises need either Datacenter licensing for those hosts or additional Standard licences — and tracking this at scale, across dynamic VM environments where instances are created and destroyed regularly, is where compliance gaps develop.
SQL Server in Virtualised Environments
SQL Server licensing in virtualised environments follows the same core-based metric as Oracle but with important differences. SQL Server Standard licences permit up to 4 cores per VM (capped). SQL Server Enterprise licences in virtualised environments require either: per-core licensing applied to all cores of the physical server (enabling unlimited VM instances of SQL Server Enterprise on that server); or per-VM core-based licensing covering all vCPUs assigned to the VM. The Enterprise licensing model for virtualised environments is similar to Oracle's in concept but Microsoft applies it at the physical server level rather than the cluster level. Our SQL Server licensing guide explains the on-premises vs Azure deployment trade-offs.
Azure Hybrid Benefit in Virtualised Environments
Microsoft's Azure Hybrid Benefit (AHB) allows enterprises with active Software Assurance to use their on-premises Windows Server and SQL Server licences for Azure VM deployments. The compliance risk arises when AHB is claimed for Azure VMs but the underlying on-premises licence with Software Assurance has expired or been terminated. As enterprises migrate workloads to Azure, maintaining accurate records of which on-premises licences with active SA are supporting AHB claims requires active management. Our Azure Hybrid Benefit guide covers the compliance requirements in detail.
Container and Kubernetes Licensing Risk
Container-based deployment represents the frontier of virtualisation licensing ambiguity. Most major software vendors have not yet published clear, contractually binding licensing policies for containerised workloads, creating a landscape where enterprises face real audit risk from ambiguous terms.
Oracle's position on containers: Oracle's database cannot be effectively run in Docker containers without significant modification, but Oracle Middleware (WebLogic, Application Server) is frequently deployed in containers. Oracle's position is that container-based deployment does not qualify as hard partitioning — the full host processor licensing requirement applies to any host running Oracle software in containers.
IBM and OpenShift: IBM software deployed in OpenShift Kubernetes clusters creates ILMT measurement challenges because ILMT cannot natively track container-based IBM workloads in the same way it tracks VM-based deployments. IBM has published guidance on CloudPak-based container deployments but the ILMT compliance picture for non-CloudPak IBM software in containers remains complex. Enterprises should seek written confirmation from IBM regarding sub-capacity eligibility for their specific containerised deployment architecture before claiming sub-capacity pricing.
Microsoft SQL Server in Linux containers: Microsoft supports SQL Server running in Linux containers and provides specific licensing guidance, but container deployments require Developer Edition for development/testing or Enterprise/Standard editions for production — and the per-core licensing metric applies to the physical host's core count, not the container's resource limits, unless the container is running on a VM already fully licensed for SQL Server.
Cloud Virtualisation and Licensing Complexity
Cloud deployment adds another layer of complexity to virtualisation licensing. Major IaaS providers — AWS, Azure, and Google Cloud — use virtualised infrastructure, and the licensing rules for running enterprise software on cloud VMs vary significantly by vendor and cloud provider.
Oracle on AWS: Oracle offers two licensing models for AWS deployments — Bring Your Own Licence (BYOL) and Oracle-provided licensing. BYOL for Oracle Database on AWS requires full physical host licensing following Oracle's Authorised Cloud Environment policy for AWS — which is effectively the same cluster-level requirement as on-premises VMware. Oracle-managed instances on OCI permit OCPU-based (fractional core) licensing, making OCI substantially more cost-effective for Oracle workloads. Many enterprises are reassessing their Oracle-on-AWS environments as the licensing cost implications become clear. See our Oracle cloud migration pitfalls guide for the licensing economics.
Mitigation: Building a Defensible Virtual Licence Position
The mitigation strategies for virtualisation licensing risk converge on a common principle: accurate, current, independently verified documentation of the deployment environment. The enterprise that can demonstrate precisely which software runs on which infrastructure, with supporting documentation of the applicable licensing rules, is in a fundamentally stronger position than the enterprise that relies on estimates or undocumented assumptions.
Oracle risk mitigation: Map all Oracle software to specific VMware clusters and document the physical host configurations. Evaluate the cost-benefit of migrating Oracle workloads to dedicated hosts, Oracle VM, or Oracle Cloud. For high-value Oracle environments, engage an Oracle licence specialist for an independent licence review before Oracle initiates one. Review your Oracle licence agreements for the specific contractual language governing virtualisation.
IBM risk mitigation: Confirm ILMT is properly installed, configured, and generating compliance reports every 90 days. Audit ILMT coverage to ensure all eligible IBM workloads are monitored. Document ILMT configuration history to evidence continuous compliance. Review any IBM workloads in containers for sub-capacity eligibility.
Microsoft risk mitigation: Conduct a Windows Server and SQL Server virtualisation licence review using your SAM platform's Microsoft licence optimisation capabilities. Validate AHB claims against active SA entitlements. Review SQL Server deployments for core-based licensing alignment with virtual and physical host configurations.
For a comprehensive audit readiness framework, see our SAM tools audit readiness guide, and for the full vendor audit response framework, the Vendor Audit Defence Handbook and the Complete Guide to Vendor Audit Defence.