Les Cunliffe - Fotolia
When it comes to Oracle products, few topics engender as much controversy and confusion as Oracle licenses, and no area of Oracle licensing causes as much frustration as licensing Oracle products in a VMware environment. The airwaves are full of misinformation and contradictions, and the messaging out of Oracle is inconsistent, vague or outright unreasonable. Those trying to run Oracle products on VMware are left with few concrete details and run the risk of an Oracle audit that could cost millions.
Customers and would-be customers often point to the scare tactics Oracle sales reps use to keep them away from VMware -- threats of astronomical licensing costs that include all servers in all clusters across the entire known universe, even if a product happens to run on only one server in one small corner of an insignificant cluster.
Adding to the confusion is the contradictory information coming from bloggers and columnists and forum participants, all offering their own opinions and experiences as they try to make sense of the licensing melee. Even VMware has come out with a white paper that attempts to serve as the definitive guide to how Oracle licensing is supposed to work in a VMware environment. Oracle has neither sanctioned the white paper nor come out with anything nearly as concrete.
That's not to say Oracle does not offer up its own reams of information. In fact, the company provides a wide assortment of documents that ostensibly try to clarify Oracle's stance on its licensing policies. However, documents like the Oracle Software Investment Guide (SIG) and Oracle Partition Policy state quite clearly that the publications are for "educational purposes only" and "may not be incorporated into any contract" and do "not constitute a contract or a commitment to any specific terms," all of which makes them less than helpful.
When it comes to licensing details on VMware, Oracle seems intent on remaining vague. The only licensing documents that appear to carry any weight are the Oracle Master Agreement (OMA), which defines the general licensing restrictions on all products, and the Ordering Document, which outlines the product-specific constraints. That said, the documents can and often do reference external licensing policy documents such as the Technical Support Policy or the Processor Core Factor Table, neither of which includes a disclaimer about the document not being "incorporated into any contract."
Oracle licensing lingo
To better understand where the controversies lie with Oracle licensing, it helps to have a basic overview of the terminology used to explain different concepts. A good place to start is with the idea of partitioning, the term Oracle uses to refer to a server whose CPUs are separated into sections, or segments. For the purposes of Oracle licensing, there are two types of partitioning:
- Soft partitioning: An operating system resource manager segments the OS to create areas where CPU resources can be allocated to a set of applications. Examples include Solaris 9 Resource Containers, HP Process Resource Manager, Affinity Management, Oracle VM and VMware.
- Hard partitioning: A server is physically segmented into distinct systems, each independent of the other, with their own CPUs, operating systems, memory and other resources. Examples include Solaris Zones, physical domains, logical partitions and Micro-Partitioning.
Oracle supports several hard partitioning technologies that can be used to determine the necessary number of software licenses required for a product. However, Oracle explicitly states that soft partitioning cannot be used to determine number of Oracle licenses needed.
Oracle supports two types of Oracle licenses: the Named User Plus (NUP) license and the Processor license. The NUP license requires that users be identified and counted and, thus, tends to be limited to smaller, controlled environments.
The Processor license is used in all the places where users can't easily be identified, such as Internet applications. It is based on the number of processor cores on the server where the Oracle product is installed or running rather than a number of users. The Processor license is the one at the center of the controversy.
To use the Processor license, you need to know the core factor, which provides the basis for determining the number of processor cores you need to license for a given environment. You can find the core factor in the Oracle Process Core Factor Table. Once you know the core factor, you multiply it by the total number of processor cores to arrive at the required number of Oracle licenses.
Licensing individual servers
Since Oracle considers VMware to be a soft partitioning technology a virtual machine (VM) cannot be used to determine the number of Oracle licenses necessary to run an Oracle application in that environment. In this case, the Processor licensing rules revert to the host system, which means, according to the Oracle SIG, "All processors where the Oracle programs are installed and/or running must be licensed." Even though the SIG is a non-binding document, it suggests that Oracle will let you run as many VMs on a server as you want, as long as you license all of the server's processor cores.
But what if you're running an Oracle product in only one VM and, as expected, only some of the processors are allocated to the VM? It would seem, according to Oracle messaging, that you're out of luck. Oracle policy appears quite clear on this fact. All processor cores must be licensed.
However, VMware's infamous white paper would suggest otherwise. It tells customers that they can use vSphere CPU Affinity to restrict VMs to specific cores and then only need to license those cores. The white paper also says that customers can use a server's BIOS to turn off some of the sockets as a way to license fewer cores.
Licensing clustered servers
If licensing Oracle in a VM on a single server seems fraught with peril, imagine what happens when you start bringing clusters into the discussion. The debate now moves from a single host to the entire cluster and whether you must license all hosts, even if you implement an Oracle product only on a subset of the hosts.
If a product is installed on or runs on all hosts, licensing is normally not an issue. Oracle, VMware and the rest of the world are, for the most part, in agreement that processor licensing requires that all machines be licensed. There still might be debate over whether an Affinity-like strategy can be used on a per-server basis, but the general guidelines remain. Oracle doesn't count the number of virtual machines, only the number of servers and their processor cores.
Suppose, however, that you're running VMs with Oracle products on only a subset of hosts -- or even just one host. As a result of technologies like VMware's vMotion, Oracle still wants you to license all hosts in the cluster, going so far as to also include all hosts managed by a vCenter server, even those outside the cluster where the Oracle product resides.
Because these technologies make it possible to move VMs from host to host, Oracle expects all hosts to be licensed. It does not matter whether the Oracle product touches only one machine. The potential for moving the VMs to other hosts appears to be cause enough for Oracle to threaten its customers with hefty penalties if unlicensed hosts are discovered during one of its notorious audits.
Despite Oracle's insistence that all hosts in a cluster (or beyond) are fair licensing game, the VMware white paper suggests that it is perfectly acceptable to license only a subset of hosts because you can use DRS Host Affinity rules to restrict VM movement within the cluster, effectively making certain hosts unavailable. In this way, you need only license the hosts where the product will run.
Nothing we've seen so far that has come out of Oracle -- whether from its sales teams, auditors or License Management Services -- suggests that Affinity is an acceptable alternative. On the other hand, those who would agree with VMware's interpretation once again point to the non-contractual nature of many of Oracle's licensing documents as well as to Oracle's own language, which states, "All processors where the Oracle programs are installed and/or running must be licensed." It does not say anything about processors that could run the Oracle program but currently are not.
The debate rages on
There remains no clear consensus on the correct way to proceed, and Oracle has yet to come out with precise and reasonable guidelines to help its customers along, other than to provide an extreme all-or-nothing view of servers and clusters. But the company still has the power to inflict costly fines for licensing violations, and fighting the Oracle machine is no small task.
Even given the ambiguity that surrounds these issues, many customers will continue to license their Oracle products based on usage and practicality, rather than the number of possible implementations. If it were to come to an audit, their only hope would be to point out the lack of contractual clarity and bring an army of attorneys. Following anything less than Oracle's version of full compliance is a risky and potentially costly strategy.
In the end, the OMA and Ordering Document appear to be the final word, stating that they replace all prior verbal and written agreements. However, even here, Oracle leaves a lot of room for uncertainty. When it comes to VMware licensing, don't make any assumptions and make sure you involve your legal team every step of the way. Oracle has chosen to make its licensing processes as difficult and confusing as possible for its VMware customers, and there's no reason to think that will change anytime soon.
Find out about a new type of Oracle license, the Perpetual Unlimited License Agreement
The Campaign for Clear Licensing calls out Oracle on its aggressive licensing policies
Discover why PULA disappeared quickly after it was announced