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.
System Builder uses virtual CPUs (vCPUs) for sizing the server compute resources. Most DBAs size servers using physical cores because Oracle licensing. I have some questions about the best practice for assigning 'virtual sockets' and 'cores per socket' when creating a Virtual Machine. I have a Dell PowerEdge T620 Server. - 2 Processor Sockets. - 6 Cores per Socket. For this *physical* machine, vCenter Server says there are 24 'Logical Processors' 1.
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. 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. 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: VMware published a white paper last year, about Oracle certification, support and licensing specific to VMware environments: 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 – Rules have changed since VMware vSphere 5.1.
Every physical host managed by the vCenter Server instance should now be fully licensed. 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.
Oracle licensing on VMware, Cloud, Hyper V and other virtualised platforms. 1. Lace Market House Nottingham NG1 1HW www.onomi.co.uk www.onomi.co.uk Do’s and Don’ts of Oracle licensing in a virtualised world Questions to [email protected] UK Dial in number is: 0330 221 9922. Introducing your Hosts: Onomi Independent Database Specialist Licensing Services Experienced Consultants 24x7 Managed Services. Free White Paper Please note that a 15-page white paper by the presenter will be provided to attendees of today’s session. This discusses more fully all the thought processes behind the topic and provides relevant sources for the information Note: all the principles I discuss in these materials reflects the generic position. Everything in life is negotiable, including Oracle contracts, for those with enough influence.
The evolution of deployment architecture Keeping an eye on Oracle’s commercial interpretation Physically- managed server Bare metal + native O/S Multiple cpus gradually evolved into highly-scalable Symmetric Multi-Processor architectures For many years cpus were single core. The evolution of deployment architecture Keeping an eye on Oracle’s commercial interpretation Physically- managed server Bare metal + native O/S Hardware Partitioning Native O/S + rigidly ring-fenced set of cpu resources. Later developed migration features Framework for managing resources. Oracle recognises specific technologies as “hardware partitioning”. Debating the meaning is futile: these are Oracle’s rules. Later developed migration features. Oracle has not accepted these as compliant with their partitioning doctrine for licensing.
The evolution of deployment architecture Keeping an eye on Oracle’s commercial interpretation Physically- managed server Bare metal + native O/S Hardware Partitioning Native O/S + rigidly ring-fenced set of cpu resources. Later developed migration features Virtualised Clusters Hypervisor with multiple, varied O/S instances and live migration It would be unwise to make the general assumption that a virtual machine can be a hardware partition for Oracle licensing. The evolution of deployment architecture Keeping an eye on Oracle’s commercial interpretation Physically- managed server Bare metal + native O/S Hardware Partitioning Native O/S + rigidly ring-fenced set of cpu resources. Later developed migration features Virtualised Clusters Hypervisor with multiple, varied O/S instances and live migration Cloud Abstraction rather than new technique, lots of variety We’ll explore types of Cloud later. The evolution of deployment architecture Keeping an eye on Oracle’s commercial interpretation Physically- managed server Bare metal + native O/S Hardware Partitioning Native O/S + rigidly ring-fenced set of cpu resources. Later developed migration features Virtualised Clusters Hypervisor with multiple, varied O/S instances and live migration Cloud Abstraction rather than new technique, lots of variety Don’t assume that the older models are now irrelevant, far from it!. Licensable Environment A term I created to clarify how Oracle’s licensing rules play out in the real world, and how you should approach measuring compliance The valid choices are simply these:- o The whole of a physically-managed server in the good old-fashioned way o An approved regime of hardware partitioning.
(NB on x86 kit, the only candidates are OVM for x86 (without live migration) or Solaris x86 running natively with capped Containers o The whole of a virtualised cluster. Generally all the above are considered equal in licensing, and many rules apply to all of them. This has some unforeseen outcomes. . Oracle has started to expand licensing scope for VMWare post vCenter 5.1. If one instance of vCenter manages multiple clusters, Oracle will say they are all potential migration targets and must be licensed. Licence Metrics The vast majority of Oracle Technology products offer a choice of Processor or Named User Plus metrics Virtualisation and Cloud have not generated new metrics, and bearing in mind the Licensable Environment concept, lets ensure the meaning of the available metrics is clear.
Named User Plus (NUP) Metric A user under this metric is a real individual (or an automated device) who interacts with the licensed system. Hence schema ownership, authentication method and connection method are all irrelevant It is NOT a measure of concurrency – prior to Sept 2002 there was a Concurrent Device (CD) metric for which some customers still retain valid contracts.