Some of my regular readers may remember an article I published titled Fight the FUD – Oracle Licensing and Support on VMware vSphere . This new article represents an addendum to my original article as some additional FUD has come to light. Hopefully this will allow you to avoid investing in licenses that will be unnecessary and unused, and thereby improve your return on your license investment. It’s again time to fight back and to stop the FUD!
In my previous article I finished off at FUD #4, so I’m going to continue the numbering into this article.
FUD #5 – HyperThreading Will Double Your License Costs on VMware vs OVM
A customer told me a while ago they had heard from an Oracle rep that if they enabled HyperThreading on their VMware environment it would double their licensing costs, but that this did not apply if they used OVM. This statement is complete rubbish, there is no other way of putting it. I couldn’t believe this when I first heard about it. Just in case someone wants to try this one on you lets go through some background and refer to some Oracle documents that will put this one to bed.
Firstly the initial resources I always recommend customers refer to when dealing with Oracle licensing is the Software Investment Guide (SIG) and the Processor Core Factor Table. You will find the definition of the different licensing metrics from page 13. I would recommend you read this carefully.
Page 13 covers the provides a high level overview of the metrics and discusses Named User Plus licensing model. If you happen to be using named user plus then the argument around number of processors regardless of HyperThreading state, is completely irrelevant. If you’re using Named User Plus you are not licensing per processor and you can throw the SIG at whoever mentioned HyperThreading would double your licensing costs and move on to read FUD #6. The same is true if you are using Standard Edition Licensing because according to page 15 of the Software Investment Guide “When licensing Oracle programs with Standard Edition One or Standard Edition in the product name, a processor is counted equivalent to an occupied socket.” However if you are using Enterprise Edition Licensing on a per processor basis please continue reading this section.
Page 15 covers the definition of what Oracle considers to be a processor and refers you to the Processor Core Factor Table. If you are using processor based licensing you must license “All processors where the Oracle programs are installed and/or running.” So how is the number of processors determined? The number of processors is “determined by multiplying the total number of cores of the processor by a core processor licensing factor specified on the Oracle Processor Core Factor Table…” So from this we can see that any cores in a multi-core processor socket, when it comes to Oracle Enterprise Edition, when multiplied by the core factor, determine the number of processors.
Immediately you can see the argument regarding HyperThreading falling apart. A HyperThread is not a processor core, it is simply an additional execution path within a processor core. Therefore HyperThreading does not impact your per processor licensing at all, period. I am not going to cover the comparison to OVM here as I have already covered the case where it could be different it in my article Fight the FUD – Oracle Licensing and Support on VMware vSphere in FUD #1 Oracle Licensing and Soft Partitioning.
FUD #6 – Using VMware vSphere 5.1 Means You Must License EVERY Host In Your Environment
This one could be quite frightening if you believed it. Could you imagine the cost of licensing every single host in your VMware environment regardless of whether they will actually run Oracle EE? Fortunately this is also complete rubbish. So why is this rubbish I hear you say? Well it’s just like Oracle saying you have to license every host in your environment that is connected to the same storage array as an Oracle EE Database server, or because you can replicate or move data between storage arrays then all servers connected to all storage arrays must be licensed. This is simply not the case. You must license what you use, but you only need to license “All processors where the Oracle programs are installed and/or running.”
The reason this FUD came about is that VMware vSphere 5.1 introduces the ability to live migrate a virtual machine between hosts even if they don’t have shared storage. In theory any host connected to a vCenter server that runs Oracle could potentially be live migrated, provided of course it meets the vMotion requirements. The reason I say connected to the same vCenter is that you can’t at this stage do live migrations between two different vCenter Servers. But with this new feature you could potentially migrate between any host in any cluster regardless of the underlying storage.
So to determine what types of Oracle Databases could be migrated live, even if they don’t have shared storage, some background on this enhanced vMotion capability in vSphere 5.1 might be in order. I would recommend you read this blog article VMware vSphere 5.1 vMotion Architecture, Performance, and Best Practices and the white paper it refers to VMware vSphere 5.1 vMotion Architecture, Performance and Best Practices. In short though any workload that is using a shared SCSI bus or shared disk cannot be live migrated using this new feature between hosts that don’t share the same storage. Immediately this will eliminate Oracle RAC clusters due to the requirement of shared disks, except perhaps a single node RAC. Therefore the only databases that might be candidates for this enhanced vMotion are stand alone databases using VMDK’s or virtual mode raw device maps (vRDM).
So does this mean you have to license every host connected to the same vCenter if a single host on that vCenter holds a standalone Oracle EE Database instance and you’re licensing per processor? In my opinion no. I believe the reasons are similar to those I outlined in Fight the FUD – Oracle Licensing and Support on VMware vSphere FUD #2 – Oracle Sub Cluster Licensing Is Not Possible. You must license “All processors where the Oracle programs are installed and/or running.” If Oracle is not installed and/or running on any hosts other than those already licensed hosts connected to your vCenter (and you can prove that it, refer to FUD #2), then you do not have to license the additional hosts. I would strongly recommend you limit access to the this new live migration functionality on the hosts where Oracle is run, and also ensure change control processes are followed. This will reduce the chances of configuration or operations errors introducing licensing risks.
[Updated 08/01/2015] With vSphere Replication now being built into the base hypervisor there could be an impact on the 10 day rule (refer to page 20 of the software investment guide). This is where you are allowed to fail over an Oracle database to another server for up to 10 days per year without licensing the additional server (check the detailed wording in your contract for exact terms and conditions). The intention of the 10 day rule is that it is to be used in a single datacenter, but some of the terms are less clear these days, including disk array. Different legal jurisdictions also have different rules with regards to how this may impact DR. As with anything Oracle related your contract is the single source of truth and is legally binding and replaces all prior written or oral agreements.
Although I have referred multiple times to the Oracle Software Investment Guide, it is just that, a Guide. It is not a contract. It is not binding. So you must review your actual Oracle contract (OLSA), the contract that has been agreed and signed by you and Oracle to determine what your actual licensing position is. You will notice on the SIG that it states it is for “educational purposes and provides guidelines regarding Oracles policies…” only. It might not be incorporated into any contract and does not constitute a contract or a commitment to any specific terms. Use this as your weapon when you find someone peddling FUD. Your diligence is the best way to protect yourself from investing in unnecessary licensing.
I strongly encourage you to seek professional advice when dealing with any licensing audits or if you want a second opinion on your Oracle licensing obligations. You must pay for what you legally owe and what you use, but no more. I know License Consulting provide this type of service in Europe and North America. You may like to seek out other companies in your region. You might like to also check out Oracle talking about VMware licensing form the VMworld TV – Oracle on Licensing VMware / Virtualized Environments (VMworld 2012) on the License Consulting site.
Keep up the good fight and beware of the return of the FUD!
This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2013 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.
[…] Fight the FUD – Oracle Licensing and Support on VMware vSphere […]
Nice job on fighting more Oracle FUD. Btw, I am starting to hear some FUD already with the yet to be released Oracle 12c that it can or should not be virtualized because of its plug fable db architecture. Don't think it's coming from Oracle corp but from some folks in the field.
[…] I have added two more items to this list of FUD in another article called Return of the FUD – Oracle Licensing on VMware vSphere. […]
[…] Oracle FUD in my articles Fight the FUD – Oracle Licensing and Support on VMware vSphere and Return of the FUD – Oracle Licensing on VMware vSphere, but my recent discussion with an Oracle Account Exec opened up even more high quality FUD from the […]
Enterprise Manager Plugin for Oracle on VMware License Optimization
Is confusion, or lack of knowledge around Oracle licensing policies and fees on VMware preventing your enterprise from leveraging the technical and business benefits of Oracle on VMware to the fullest?
Blue Medora is seeking interested Beta participants to help us validate the features and functionality of a new Oracle Enterprise Manager (Oracle EM) Plugin, the Blue Medora Oracle Enterprise Manager (12c) Plugin for Oracle on VMware License Optimization.
The plugin provides an Oracle-based solution to the problem of managing Oracle workloads on VMware mixed Cluster environments where virtual machine mobility dramatically increases the risk of Oracle license over deployment and overspending.
The primary functionality provided by the plugin includes:
• Reduce the risk of over deploying Oracle licenses within VMware Clusters
• Mapping of virtualized Oracle workloads to the physical VMware ESX hosts
• Detection, alerting, and remediation recommendations for vMotion and DRS Host Affinity related configuration issues
• Recommendations for improved license optimization of VMware virtualized Oracle workloads
if you are interested in seeing more detailed information about the EM12c Plugin for Oracle on VMware License Optimization, and/or you would like to participate in our beta program for this release, please view the page and beta request form by clicking this link:
We greatly appreciate your input on this matter, so even if you do not want to be a beta participant, please consider sharing your thoughts on whether this set of capabilities would provide value to you and your enterprise. We are always interested in what customers think; especially when it comes to extending the reach of Enterprise Manager!
[…] license compliance issues and will include support for sub-cluster configurations, as per FUD #1, #5 and #6 […]
another return of the FUD: https://communities.vmware.com/thread/490514
Thanks Tobias, this is indeed more FUD and is not correct. The requirement remains to licenses where Oracle Software is installed and/or running. Therefore only the hosts where this is true need to be licensed. They can not legally enforce you to license any other hosts in your environment if the Oracle software does not run on them. If however you move the Oracle software to an unlicensed host, then you will have to license that host. This is why we recommend to use one of the various means to isolate the Oracle software to licensed hosts.
[…] FUD in my articles titled Fight the FUD – Oracle Licensing and Support on VMware vSphere and Return of the FUD – Oracle Licensing on VMware vSphere. It refers to an post on the VMware Communities site here. But let me summarise this for […]
Your statement about vSphere Replication falling into the “10 day” rule seems inaccurate. Oracle clearly states that “The above right only applies when a number of machines are arranged in a cluster and share one disk array.” The thing is that when using vSphere Replication between two datacenters for DR purposes, you’ll always be using at least 2 disk arrays and not one. This would mean the “10 day” rule simply does not apply in this setup.
This area is still a little grey as it depends on jurisdiction potentially (EU has different rules than the US for this area). But I think this does justify some changes as the 10 day rule intention is for a clustered system in a single datacenter. But it\’s not so easy to define a disk array these days. Especially when that may include stretched metro cluster environments, which are logically a single disk array.