Oracle Licensing in Virtual Environments
Virtualisation has been around in various forms for decades however, it was originally found on enterprise-class hardware: mainframes, IBM Power-based frames and large ‘chassis’ machines. With the introduction and wide adoption of VMware over the last 15 years or so, the accessibility of virtualisation has become much easier using commodity-class hardware.
Virtualising Oracle workloads took longer for businesses to have the level of comfort they needed to ensure performance and support were not impacted. As more customers have moved to VMware, Oracle has had to evolve its practices to ensure that significant impacts were not felt by both their support and license organisations: while less hardware means less license revenue, this needs to be balanced with derived business value for the licensee.
This has ultimately evolved into a complex ‘ecosystem’ that has changed significantly over the last 10 years leaving customers, and indeed all but the most closely involved in this evolution, generally confused.
Oracle licensing in a virtual environment has long been a cause for concern for Oracle customers, to the point where some customers still refuse to put their Oracle workloads on VMware. Although more and more people are considering moving Oracle workloads to the cloud, virtualisation remains a relevant question — either as a private cloud platform or to consolidate the estate instead of a move to the cloud. Crucially, we still see customers being presented with very large bills arising from virtualisation. This can lead to unnecessary license purchases and even unwarranted and inappropriate ULAs.
As with many aspects of Oracle licensing, this is an in-depth topic but this blog aims to clarify the background, position and approach to licensing Oracle deployed on VMware. In summary;
There should be no reason for you to avoid running Oracle on virtual environments. Over 96% of our enterprise customers use VMware for Oracle workloads: there’s no single solution for all of them, a considered approach is required.
Background
The concept of licensing technology products on a metric related to the associated processing power makes sense: a big server will typically be running more important workloads, and the technology product will be delivering more value (due to the increased number of processors). This has been a long-standing mechanism for paying a license fee proportional to the value derived.
With the increased adoption of X86-based virtualisation towards the late 2000s and into the 2010s, there was significant uptake of VMware in enterprises. Consolidating many dedicated physical servers into VMware hosts, increasing CPU utilisation, reducing hardware footprint and costs were major benefits achievable by anyone willing to pay the VMware license fee. Inevitably, this meant that Oracle workloads slowly but surely became potential targets to virtualise: more utilisation, less license.
It is worth thinking about this for a second: consolidation of many inefficient underutilised servers into fewer optimised physical hosts means an overall reduction of processing power allocated to workloads. Instead of having two 16 core servers running at 20% CPU utilisation, I can easily virtualise these and consume <7 cores (which in reality would fit into 8 cores): a reduction of 80%. 32 cores down to 8 is an impressive reduction. Most importantly for our discussion: this, therefore (simplistically) reduces the license fee due to Oracle by 75% by optimising the load balance of the processors I have.
Evolution and Functionality Changes
As time progressed, Oracle flagged concerns about their ability to support (technically) Oracle running on VMware: leading to customers being wary about virtualisation. In reality, the perceived risk never really materialised: Oracle certify a combination of their products with a given operating system — they do not certify against the underlying platform or server. This concern has waned and there is no evidence nor have we heard of a customer being required to reproduce an issue on a physical server to receive support.
Support should never have been a concern for running Oracle on VMware
The next change came when there was a realisation by Oracle that VMware offered more than just the ability to consolidate workloads: VMs can be live migrated between physical hosts. This means that a workload can be seamlessly (to the users) moved from a given VMware server to another in the VMware environment. This ability to migrate Oracle workloads between different physical servers was interpreted by Oracle to mean potential servers also need to be licensed.
In the early releases, this vMotion ability was limited to a given cluster: a virtual machine running Oracle software could live to migrate and reside on any other host in the cluster. Oracle, therefore, required customers to license all hosts in a cluster where a VM running Oracle resided as, in their view, any of the potential hosts require a license.
As VMware functionality increased, it became possible to migrate a VM around between any of the clusters, as long as they were managed by a single vCenter. Oracle adapted their licensing practice to reflect: in these versions of vCenter (5.1–5.5), all hosts in all clusters under a vCenter needed to be licensed as all hosts were potential targets for the VM to run.
In later incarnations of VMware (6.0+), it is possible even to move a VM between hosts managed by different vCenters, as well as migrating to the cloud. Once again, an evolution in licensing rules was instigated by Oracle to reflect this new capability: all ESX hosts under vCenters running this later version of VMware needed to be licensed. To reiterate: ALL VMware hosts (at that version) needed to be licensed; there is no effective license boundary.
In summary, the policy effectively dictates the following; much of this now relates to really old versions of VMware, these are included only for the sake of interest and showing the evolution of the policy. Broadly speaking, the ‘by version’ rules are as follows:
- VMware 5.0 and earlier: license all hosts of any cluster where an Oracle product exists
- VMware 5.1–5.5: license all hosts under a given vCenter where an Oracle product exists
- VMware 6.0 and above: license all hosts running this version of ESX irrespective of vCenter where an Oracle product exists
Related read: How to Modernise Your Existing Applications for Greater Innovation and Agility
Communications and Contracts
The above has a significant impact on licensing, so one would expect that this is very clearly and explicitly set out in license/contractual terms. To date, that has not been the case. The only document which references VMware which relates to licensing is Oracle’s hard partitioning document (link). This document guides how Oracle expects customers to license and what technologies can be used to license servers on a sub-capacity basis: i.e. what can customers do within a single server by adjusting processor configurations to reduce license allocation. While the document states that VMware is Soft Partitioning: there is no further detail, no insight on the variable rules outlined above.
This is something of a conundrum. How can customers be expected to ensure that they are licensed properly when the rules are seemingly not definitively set out or published anywhere?
Next problem: this Hard Partitioning document is non-contractual and for educational purposes only. This means that it does not get referenced from a customer’s ordering documentation or master agreement (OMA/OLSA) — this is clarified by the Entire Agreement clause which makes it clear that the “complete agreement” is the order plus the master agreement plus contractually referenced policy/information. The Hard Partitioning document is not referenced: and while it is used by Oracle to count their view of licenses required it is worth remembering that as it is not contractual, it is not binding on customers in any way to adhere to. Like any other vendor, and Oracle license contract is between Oracle and the licensee: only the contents of the contract are binding. Any calculations whether documented or not, that are not included in the contract, are not subject to contract and therefore can be challenged.
So, what does a typical customer contract state?
Processor: is defined as all processors where the software is installed and/or running.
There is no reference to VMware, clustering (ignoring the Failover clause which talks about active-passive clusters) or virtualisation.
The Processor definition is the sole basis on which customers are contractually obliged to license their use of the software.
The Oracle VMware policy would therefore seem to hinge on the word “installed” from the Processor definition: it is clear and evident on which Processors Oracle’s software is running: the physical server running a virtual machine with Oracle software on it. Oracle’s assertion is that the potential of any host to accommodate the migration of an Oracle workload constitutes an installation however, it could be said that any reasonable interpretation of an installation would be predicated on the ability to immediately start and use the software: which self-evidently, can only take place from the VM within which the software is installed.
Thinking about this, given a single VM with Oracle software and, say 100 VMware hosts, the biggest amount of processing power that could ever be consumed is equal to the largest physical host in the set of 100 hosts. Let’s say all the hosts have 48 cores. During typical operation, the VM (and Oracle’s software) could be installed and/or running on 48 cores (in reality, likely to be a lot less due to the virtual CPU (vCPU) allocation for the VM). There is no way for anything more than 48 cores to be consumed during normal operation; the Oracle software can only ever give the customer 48-cores-worth of processing power/benefit.
This resolves into the following situation: 48 cores of business benefit are being derived from Oracle software which should be licensed for 4,800 cores according to Oracle practice, which includes a license for 4752 cores, none of which will/can ever be used to host Oracle workloads.
If we set up our VM to have vMotion capability, it initially seems logical there must be a point at which the software is available on two physical servers (the source and target servers) via the ‘old’ and ‘new’ VMs (still ‘only’ a total of 96 cores ‘running’ the software). Once you dig into the technical detail of vMotion (which we’ll not do here!), this isn’t the case — there would never be a situation where the Oracle software would be accessible from both hosts at the same time nor would there be a situation where both the target and source VM vCPUs will be able to run the software at the same time. As a user, I would connect to one instance only — — there is not 2x the business benefit being given here, there’s no load balancing meaning twice the capacity is being delivered. Once again, the business benefit is 48 cores and not 96.
Audit
So… there is no technical nor contractual reason to license as per the logic above but it continues to happen because the audit process is undertaken by Oracle, or its Joint Partner Engagement (“JPE”) (link) partners. They request scripts to be run that simply collect a full set of VMware hosts (including processor configuration): which doesn’t reflect the contingent nature of much of the ‘installed’ cores.
In an audit scenario, customers need to provide reasonable assistance to Oracle but this should only include the relevant elements of the estate and not necessarily that demanded by vendor scripts/data collection processes.
There is a case to be made here that you also have a right to determine what is reasonable
and
Is it reasonable that Oracle knows everything about your estate including servers where Oracle will never run?
Even for customers who choose to implement good estate management by isolating or grouping workloads (clustering, host affinity and the like) according to their characteristics or ensuring collection of logs to prove VM placement historically — this will not be accepted by Oracle as bona fide measures to reduce one’s license requirements.
This is an all-too-common situation for customers and people being audited; it has caused grief (and significant license claims) for many unsuspecting licensees. As a result, it is sometimes possible to either proactively or ‘after the event’ get Oracle to ascribe certain ‘approved’ mechanisms to limit license requirements — this constitutes a means to frustrate the ability to vMotion workloads; in particular using network and disk segregation. Oracle reserve the right to ‘approve’ (or not) certain mechanisms you may implement to limit workload migrations and typically expect a set of architectural and technical detail to be submitted to gain their approval which can take some time to be secured.
Furthermore, it is also possible to have expanded specific language placed into contracts to outline the basis for licensing based on the isolation mechanisms mentioned above.
In reality, it is not trivial to gain such approval from Oracle plus it adds considerable overhead to your network and storage administrators. Additionally, this type of isolation makes sense for database/application server technologies, however, it is very hard to do the same for workloads where Oracle Java is deployed which are by its nature ubiquitous across many estates and not typically segregated.
Options
Taking all this into consideration, several alternatives can be considered for customers (note we are summarising a complex topic into a simple list here!):
1) Follow the VMware policy and abide by the unpublished and non-contractual rules
2) Approach Oracle to authorise your disk and network isolation, manage workloads to ensure they reside only in such environments
3) Implement disk and network isolation without recourse to Oracle which will require subsequent approval in the event of an audit
4) In the event of an audit, release only the requisite data for those ESX servers where Oracle software is installed and/or running:i.e. where the VMs with Oracle installations reside
5) Utilise an alternate virtualisation technology: you will still have to undergo an assessment as outlined above though
Summary
We see each of these options in use across customers globally — careful consideration is required to understand the intricacies, risks, costs and benefits. You should ensure you are familiar with every aspect of your contract as well as Oracle’s likely response before you settle upon a single option. Additionally, all relevant parties in your company must understand the policy you adopt and how this affects your licensing.
At the end of the day, remember: a license fee for a technology product should be grounded in the value you get out of it: i.e. a fee proportional to the benefit the licensed product is giving you.
Any reasonable view of the VMware policy as applied by Oracle would question how a potential host gives you value
The longevity of this policy means that it has become accepted and often not questioned: leaving businesses migrating away from or avoiding entirely the benefits that VMware can offer.
Remember also that you are paying VMware a license fee for the ability to vMotion workloads around. Using VMware, Oracle products, and indeed many other vendor’s products, are migrated in a transparent and controlled way with no dependency on any Oracle/product vendor input or integration.
As mentioned at the start, this is a complex subject with many subtleties, and what looks like a sure-fire way to optimise licensing and processing costs can result in unintended license liabilities if the wrong approach is chosen.
We have extensive experience working with customers and Oracle to realise potential cost savings for the former and ensuring license compliance for the latter. If you have any questions on virtualisation or any other Oracle licensing topic, feel free to contact me or talk to us.
About The Author
Paul Bullen is a Principal Oracle License Consultant & Practice Lead here at Version 1.
