In this post, I would like to share with you what I have learned about Oracle licensing particularities on a virtualization infrastructure (software partitioning) based on VMware ESX. Recently, I faced an Oracle licensing problem on a VMware ESX cluster on which I had to find a workaround in order to make the hardware comply with the customer’s licensing model. Without entering in details, the customer had a VMware cluster with three nodes and had not enough licenses to meet the Oracle licensing requirement.

Remember that Oracle offers two types of licensing:

  • Named user, not described in this blog
  • Physical processor, which I will discuss here

The physical processor licensing model depends on the Oracle product.
For Standard database edition, the processor is licensed per socket: You need as many licenses as sockets used by the server running the Oracle product.
For Enterprise database edition, the processor is licensed per core. A core factor is applied according to the model, the type, and the number of cores of the processor.

The formula is:
number of processor x number of cores x core factor

For example, the core factor of an Intel or AMD processor is 0.5. The number of licenses required for an Intel or AMD quad core processor is 2 (1 x 4 x 0.5 = 2).

You can find the complete Oracle processor core factor table on http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf.

But what happens if the database is running on a virtual machine, such as VMware ESX virtual machine? Maybe the licensing is based on the virtual processors allocated to the virtual machine? Unfortunately, not.

In the case of ESX virtualization, the licensing is always based on the physical hardware: If the database is running on a virtual machine, hosted on a multi-processor physical host, all processors of the physical host must be licensed, even if the database has only one virtual processor.

Worse, if the database is running on a virtual machine within an ESX cluster, all physical processors of this cluster must be licensed. Why? Remember that the aim of a cluster is to allow load balancing or failover of resources (here, we speak about database virtual machines) between the cluster members. So a database virtual machine can potentially run on any of the hosts in the cluster.

The reason of this licensing policy is that Oracle does not recognize software partitioning (virtualization) as a valid partitioning for the processor licensing. The following document explains what is partitioning, and which technology is an Oracle trusted partition: http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf

VMware published a white paper last year, about Oracle certification, support and licensing specific to VMware environments: http://www.vmware.com/files/pdf/solutions/oracle/Understanding_Oracle_Certification_Support_Licensing_VMware_environments.pdf

This white paper pointed out the DRS Host and CPU affinity rules benefits within a cluster.

DRS Host affinity

The VMware DRS Host affinity allows to specify one host or a group of hosts on which one or a group of virtual machine can run, in order to limit the virtual machines movement within a cluster. This can be very useful for software which requires fully licensed hosts (this is the case of Oracle). By this way, we can limit the number of physical hosts on which a software can run within the cluster, and at the same time, the number of CPU to license in the cluster.

CPU affinity

The VMware CPU affinity allows to specify physical processor(s) of an ESX to use with one or a group of virtual machine. It makes it possible to virtually “disable” one or many processors of an ESX Server, by hiding these processors in some virtual machines in order to reduce the number of CPU to license in the cluster.

What VMware says

According to VMware and its white paper, the CPU affinity is not recognized by Oracle as a valid partitioning solution. But the DRS Host affinity is neither accepted nor rejected by Oracle, since Oracle has no official position about it.

Based on this, it is absolutely possible to use the DRS Host affinity rules to limit the movement of Oracle virtual machines within the cluster, and to reduce the number of processors to license for Oracle products. As long as the customer keeps tracks of the virtual machine movements and can demonstrate that its virtual machines only run on licensed hosts, a fully licensed Oracle-dedicated ESX cluster is not necessary anymore.

Oracle’s position

To find out Oracle’s position on this topic, we asked an Oracle LMS consultant (License Management Services) if the VMware DRS Host affinity rules represent a valid partitioning solution for the Oracle physical processor licensing model. The response clearly was negative. I have not found any official document or Metalink note to confirm this response. But, based on the simple fact that VMware is soft partitioning, Oracle says that the whole ESX cluster must be licensed.

[EDIT – 20.01.2015]

Rules have changed since VMware vSphere 5.1. Every physical host managed by the vCenter Server instance should now be fully licensed.

See “Licensing of VMware on Oracle” in Gregory’s blog for more information.

Conclusion

Running an Oracle database on a virtual environment always requires to license all the physical processors of the physical host. Within a cluster, all physical processors of any physical hosts member of the cluster must be licensed, even if DRS Host / CPU affinity rules are enabled.

One positive thing is that once the physical host is fully licensed, the number of virtual machines running Oracle database instances is not limited.