Fight the FUD – Oracle Licensing and Support on VMware vSphere

In this post I will copy-paste one of the Best reading for Virtualizing Business Critical Applications from Michael Webster’s blog. This can explain that Oracle Database can be virtualized in VMware! Enjoy!
These are the source :
http://longwhiteclouds.com/2012/07/21/fight-the-fud-oracle-licensing-and-support-on-vmware-vsphere
http://longwhiteclouds.com/2013/01/17/return-of-the-fud-oracle-licensing-on-vmware-vsphere/
http://www.vmware.com/files/pdf/techpaper/vmw-understanding-oracle-certification-supportlicensing-environments.pdf
—-
 
I keep hearing stories from Customers and Prospects where Oracle appears to be trying to deceive them for the purposes of extorting more license money from them than they are legally required to pay. I also keep hearing stories of Oracle telling them they would not be supported if they virtualized their Oracle systems on VMware vSphere. This has gone on now for far too long and it’s time to fight back and stop the FUD (Fear, Uncertainty, Doubt)!
In my opinion the best way for you to prevent this situation for your company is by knowing the right questions to ask, and by knowing what your obligations are. The aim for this article is to give you the tools to pay only what you legally owe, while making the most efficient and economic use of your licenses, and get the world class support that you are used to, even in a virtualized environment on VMware vSphere. All without sacrificing availability or performance.
I’m going to start this article by quoting Dave Welch, CTO, House of Brick – “I believe in paying every penny I owe. However, beyond that, it is my discretion to who or what I donate and in what amount. I have no patience with individuals or entities that premeditate the creation of OLSA compliance issues.  I similarly have no patience with the knowing spreading of FUD by some professionals in what could be construed as extortion of funds beyond customers’ executed contractual obligations. I will continue to vigorously promote and defend the legal rights of both software vendors and their customers even if that means I induce accelerated hair loss through rapid, frequent hat swapping.” Source Jeff Browning‘s EMC Communities article – Comments by Dave Welch of House of Brick on Oracle on VMware Licensing.
I agree with Dave on this. So I am going to show you how you can pay what you owe, while using what you pay for as efficiently and cost effectively as possible, and show you how you can still enjoy the full support you are entitled to. Without the scaremongering that sometimes accompanies discussions with Oracle Sales Reps.
For those that aren’t familiar with the term FUD, it is an acronym which stands for Fear, Uncertainty and Doubt. Something some companies and professionals seem to go to great lengths to create in the minds of customers.
FUD #1 – Oracle Licensing and Soft Partitioning
Oracle’s Server/Hardware Partitioning document outlines the different types of partitioning and how they impact licensing. Oracle may try and tell you that licensing a VMware environment will be more expensive as they don’t consider VMware Hard Partitioning. This is complete rubbish. This assertion is completely irrelevant unless you were only planning on deploying a single small database on a very small subset of a very large server. In this case you probably wouldn’t be using Enterprise Edition and may not be paying per CPU Core (Named User Plus instead). Why would you deploy such a system when you could easily purchase a server that is the right size for the job and licensed appropriately for the job? There is absolutely no requirement to run Oracle Enterprise Edition just because you are virtualizing your databases.
There is absolutely no increase in licensing costs over and above what you would have to pay for the same physical infrastructure to run your Oracle Database if you were running it in the OS without virtualization. You still have to pay what you owe, for what you use. The truth is that your costs could actually be significantly less when virtualizing on VMware vSphere as you can get more productive work done for the same amount of physical hardware, and therefore the license requirements and your costs will be significantly less. This is because you can run multiple Oracle databases on the same server and effectively share the resources, including memory, provided you take care during your design to ensure any undesirable performance impacts are avoided.  Take this image for example showing consolidating two dissimilar workloads on the same hardware (Source: VMware).

Even if you only want to deploy a single database server you are significantly better off if you right size the host server and VM and deploy it isolated out of a cluster, but still virtualized, even if it is the only VM on the host. This will allow you to still take advantage of many of the benefits of virtualization, such as significantly easier disaster recovery due to the complete hardware independence, better monitoring via your existing virtualization monitoring tools, the ability to run unlimited number of database VM’s on the fully licensed host server. If you want high availability and non-disruptive maintenance and upgrades then you just need to add a second fully licensed host server. You can still make use of all the resources of both servers.
I discussed in my article Oracle RAC 11g R2 Standard Edition on vSphere how you could deploy up to 4 VMware vSphere hosts with a single CPU socket each to run an unlimited number of Oracle Standard Edition Databases, including Oracle RAC. This is an incredibly cost effective solution, especially as Oracle Standard Edition is not memory limited, and is licensed by processor up to a maximum of 4 sockets per host, but unlimited cores. You still pay per core, but significantly less. You should make yourself familiar with the different Oracle Database Editions and their limitations.  When you virtualize on vSphere because you get HA you may be able to downgrade some Oracle Enterprise Edition licenses to Standard Edition and potentially make a significant saving, at least in maintenance costs. You also gain effective resource isolation capabilities without having to use Oracle Database Enterprise Edition. Remember what I said before, there is no requirement to run Enterprise Edition when you virtualize your databases, you can run any of the editions provided you deploy them within the license and technical restrictions. In all cases you must ensure that all processors are licensed for Standard Edition in compliance with the OLSA and Software Investment Guide.
If you are using Oracle Database Enterprise Edition there is an opportunity to save significant amounts of money if you are migrating from traditional Unix platforms to Linux or Windows running on VMware vSphere. This is due to the way that Oracle calculates the CPU Core License Factor. The Intel CPU’s have a Core License Factor of 0.5 compared with some of the higher end traditional Unix platforms Core License Factor of 1.0. This means you need half as many licenses to cover the same number of of Intel CPU Cores as you have in your traditional Unix platform. Oracle may say that’s because the Intel systems are inferior and don’t perform. However based on my experience modern x86-64 hardware will outperform most of their Unix counterparts. In some cases you can achieve up to 5x the performance compared to a traditional Unix system when utilizing the same amount of licensed hardware (One of my customers did). Not that the new SPARC T4 Processor now has a 0.5 core factor, the same as an Intel Xeon CPU. I take this to mean Oracle recognises the power of the Xeon chips, but one key thing to note is that the SPARC T4 is over twice the price per core as the Intel Xeon counter parts.
The real hard dollar licensing savings here will come into play when re-negotiating maintenance if you already own all the perpetual licenses you need. It will also come into play if you expand the environment as you will be able to avoid purchasing any additional licenses, seeing as you have spare licenses after the switch to the x86-64 platform.  If you are in a position where you need to expand the environment and you’re on a traditional Unix, now might be the perfect time to make the switch and put the additional license money into the cost of the migration project instead. I have outlined in a previous article what I think are the Top 10 Reasons to Migrate Oracle Databases from Traditional Unix to Linux on vSphere. License Maintenance costs are not the only cost savings by switching to x86-64 from traditional Unix, you may also save significant amounts of power, cooling, data center floor space and hardware maintenance costs. In one of my recent projects the 15 months of the cost of the traditional Unix platform hardware maintenance paid for the entire project costs to switch, services, software and hardware.
If you have an uncapped ELA (ULA in Oracle Terms – Unlimited License Agreement) you can deploy the database software wherever you like the whole discussion about soft or hard partitioning, or the number of cores, is completely irrelevant. You should deploy as many databases as possible and make the best use of your software entitlement. This will come into play quite strongly with my next FUD item below. Be careful to only use the features you are licensed for however, so you don’t get any nasty surprises come audit or ELA/ULA renewal time (provided your use is within your OLSA agreement).
FUD #2 – Oracle Sub Cluster Licensing is Not Possible
Still on the licensing topic, but this area of FUD comes into play when you want to only license a subset of hosts that make up part of a large cluster for use by Oracle. Contrary to what many might believe or try and tell you it is fairly easy to deploy and license a subset of a larger VMware vSphere Cluster. It is also perfectly acceptable under the Oracle Software License Agreement, provided you can prove that the Oracle binaries have only been executed/run on the systems that make up the subset of the cluster. Now just because you can do this doesn’t necessarily mean I would recommend it and after I explain how you can do it I’ll tell you why in many cases this might not be a good idea, and it has largely nothing to do with licensing.
If you don’t have a copy of your signed and executed Oracle License and Services Agreement (OLSA) you should get one and read it thoroughly. You should also become familiar with the Oracle Software Investment Guide and the Oracle Licensing Data Recovery Environments Guide, which is an extract from the Software Investment Guide. I would advise that you get a copy of the Software License Investment Guide and Licensing Data Recovery Environments Guide that was valid at the date you signed your Oracle Software License Agreement. This will ensure you know what the policy that applied to you at the date you signed the agreement.
Before we even get into the mechanics of this you won’t have to even worry about this if you have an uncapped ELA or ULA. If you have an uncapped ELA or ULA you can run your databases anywhere and everywhere, and it’s in your best interests to do so as it will mean come true-up or renewal time all your clusters will be covered and fully licensed (dependant on the wording of your specific OLSA). The following will only be a concern if you are licensed with a capped or limited license agreement, or you do not have an ULA. If Oracle tries to use this as an objection for virtualizing on VMware vSphere just ask them this: “Why is sub cluster licensing even a relevant reason not to virtualize given we have an uncapped ELA or ULA?”  One of my customers asked Oracle this and Oracle agreed it wasn’t relevant. The same applies if you are licensed under Named User Plus.
The following is an extract from Dave Welch’s comments with regard to the Oracle Software License Agreement and Oracle Software License Investment Guide with regard to processor based licensing:
“Customers must license all physical cores or sockets on a host where Oracle executables are “installed and/or running” (with physical cores factored per Oracle’s published Core Factor Table, and potentially subject to the so-called 10-day rule [whose terms became more restrictive sometime during 2007]). Notice the tense. Oracle customers are contractually obligated for licensing the physical servers where the Oracle executables are and have been, not where they might go. To imply otherwise without explicit contractual inducement would not be unlike concluding that I am legally obligated to purchase transportation to or obtain a visa for destinations that I clearly have the capability of visiting but where I have neither ever been nor yet made a determination to even visit.”
“Furthermore, customers must pay a license to cover the use of remote mirroring at the storage unit or shared disk array layer to transmit Oracle executables to a SAN whether or not that set of Oracle executables is “installed and/or running” on any physical host connected to the SAN.”
So you can tell from the above you must be able to prove where the binaries are installed and/or running or where they have been installed and/or running. Regardless if the mechanism is manual or automatic. I strongly recommend that you read the Certification of an Oracle ULA Agreement (or: Need to defuse a time bomb) article posted on the License Consulting blog. It will give you some insight into the Oracle Audit and Certification process and some really big traps you need to try and avoid.
I will discuss both manual and automated ways of ensuring license compliance, but first lets contemplate for a moment a situation in an unvirtualized environment where you’ve taken a snapshot of a production systems LUN’s and presented them to another system. Both the production system and the new system must be fully licensed. This is fine, and you would know which systems the binaries are installed and/or running on as you have had to go to a lot of effort to snapshot the LUN’s and present them. This changes a bit when you are running in a large cluster.
License Isolation Method #1 – Storage Zoning / Masking to a Subset of Cluster Hosts
VMware Best Practices recommend that you present all LUNs to every host within a cluster. Under normal circumstances this makes perfect sense and is definitely the best option. However if you wanted to license a subset of the cluster for Oracle you might choose to zone and mask the Oracle LUN’s/Datastores to only the hosts within the cluster that will run Oracle. This will prevent the virtual machines without some further manual actions to run on any other hosts within the cluster. You can still have DRS enabled in fully automated mode and it can happily migrate the Oracle VM’s around the hosts that are licensed and zoned/masked to the storage. This has an advantage of being fairly easy to administer and manage. This still allows the use of Maintenance Mode and VMware HA. One of the major downsides here is you could easily reach the maximum number of LUNs per Host if your databases consume multiple LUNs and the rest of the non-Oracle VM LUNs are also zoned/masked to the Oracle Hosts. If those non-Oracle LUNs are not zoned or masked to the Oracle hosts then I’d question why you aren’t choosing method 4 below.
License Isolation Method #2 – DRS Set to Manual or Disabled for Oracle VM’s
This method will allow you to run all the hosts in a DRS cluster fully automated while restricting the movement of the Oracle VM’s. Administrators would have to manually move the VM’s, which would add administrative and management overheads. License compliance would be maintained provided the administrators only moved the VM’s to licensed hosts. You would need vMotion logs or an audit trail to prove which systems the Oracle software were/are installed and/or running. You may need to disable these VM’s from VMware HA to ensure there was no possibility of the Oracle software being installed and/or running on an unlicensed host. Given the chances of error and the difficulty introduced in managing the cluster this method is not recommended, even though it will meet the license conditions provided it is configured and administered correctly. Suffers from the same limitation as method 1 with regard to likelihood of reaching max number of LUNs per host.
License Isolation Method #3 – DRS Host Groups
This method allows you to ensure the Oracle VM’s are only installed and/or running on a subset of the hosts within a cluster without any special storage configuration and also with the DRS cluster remaining fully automatic when used in combination with DRS Must Rules. This is fairly easy to administer and allows for the use of maintenance mode and VMware HA. You can use the advanced option ForceAffinePoweron to ensure the VM’s will only be restarted by HA on a fully licensed host when there is a host failure. You will need vMotion Logs, or an audit trial of some sort to be able to prove where the Oracle software was/is installed and/or running. Suffers from the same limitation as method 1 with regard to likelihood of reaching max number of LUNs per host. There was a video recorded with Richard Garsthagen of Oracle on VMworld TV during VMworld US 2012. The video can be viewed in this article on the License Consulting Blog – VMworld – Richard Garsthagen (Oracle) on licensing VMware / virtualized environments.
License Isolation Method #4 – Dedicated Oracle Cluster
While not technically a way of deploying a sub cluster of hosts for Oracle inside of a larger cluster this is often my preferred method of deployment. The main reason this is generally my preferred deployment method is because of it’s simplicity. Other reasons include:
You know the VM’s will only be running within this cluster, so you can license the whole cluster and be done with it.
You can ensure you make optimal use of your licensed hardware without any non-Oracle VM’s consuming valuable infrastructure that is licensed for use by Oracle.
This allows an easier isolation of resources, as you will not have any non-Oracle VM’s consuming resources as would be the case with method 1, 2 and 3.
You can run a different consolidation or overcommitment ratio for the Oracle Cluster, which you might want to do for availability and performance reasons.
You can right size the infrastructure for your exact Oracle requirements (smaller or larger hosts and NUMA node sizes).
No complicated settings for VMware HA and no risk of a VM restarting on an unlicensed host in the case of a host failure.
Much easier from an audit and compliance perspective.
Less likely to reach the limit of the maximum number of LUNs per Host compared to method 1, 2 or 3.
Much lower likelihood of human error causing a licensing compliance issue.
With a properly designed dedicated cluster for Oracle you can make efficient and optimal use of your physical licensed hardware while still allowing maintenance and failure capacity. I disagree that this is significantly harder to manage than having a subset of hosts in a larger cluster. I actually argue that this is far more efficient to manage, especially given the need to ensure license compliance and the financial consequences of getting it wrong and the much lower likelihood of human error. Even if your dedicated cluster has only 2 or 3 hosts it still has a number of benefits. Probably one of the most significant benefits is the reduced likelihood of reaching the maximum number of LUNs per host. If you are running a big Oracle environment this is a very real possibility especially if your databases demand maximum performance and are therefore configured with multiple LUNs each.
Audit and Compliance Made Easy
Although vMotion Logs may be an acceptable way to provide proof of where Oracle software was/is installed and/or running my preferred method would be to use vCenter Configuration Manager (vCM). vCM is a tool that is purpose built to ensure audit and compliance and configuration management. It will track every modification to configuration items including vMotion Migrations. It is also used to ensure regulatory compliance with standards such as HIPPA, SOX, PCI DSS, DISA STIG and others. vCM is accredited as a SCAP 1.0 tool. It is relatively easy to get up and running and produces all the necessary reports once it has been configured. It can be purchased in isolation or as part of the vCenter Operations Enterprise or Enterprise Plus Edition Suites. vCM is not limited to compliance of virtual machines and VMware environments, it also supports physical systems, including workstations and traditional Unix systems. I would strongly recommend you consider this given the direct integration with the VMware vSphere environment and the tremendous value it can add to your entire virtual and physical infrastructures.
If you didn’t want to use vCM you may want to consider another tool such as SPLUNK, which allows for secure storage of log records and easy visualization of those logs.
FUD #3 – Oracle is NOT Certified to Run on VMware vSphere
This isn’t FUD, it’s true. Oracle isn’t certified to run on VMware vSphere. This is because Oracle does not certify below the Operating Systems. So your system isn’t certified to run on Dell, HP, or IBM hardware either. Oracle instead certifies the operating systems that run their software. So provided you are running a fully certified and supported version of the OS then you are covered. This is because VMware does not modify the OS. This topic is covered in the Understanding Oracle Certification, Support and Licensing for VMware Environments white paper published by VMware.
FUD #4 – Oracle Does NOT Support Running on VMware vSphere
Is Oracle trying to tell you that if you virtualize on VMware vSphere that you won’t get support? Are they saying that they will fail to meet their contractual obligations and support the software that you’ve potentially paid millions of dollars for? That although your running on a certified and supported OS, that because you’ve changed the underlying hardware that they won’t support you any longer? Or are they just saying you will have to move your databases back to physical if there is a support problem?
I’ve heard all of the above, and still do sometimes. It’s very surprising given that Oracle has been supported on VMware since 2007 and Oracle RAC 11g R2 (11.2.0.2) has been supported on VMware vSphere 4 and above since November 2010. Oracle has a very explicit support statement when it comes to operating in a VMware environment. The support statement is covered in Metalink 249212.1 and an extract is below:
“Support Status for VMware Virtualized Environments
————————————————–
Oracle has not certified any of its products on VMware virtualized environments. Oracle Support will assist customers running Oracle products on VMware in the following manner: Oracle will only provide support for issues that either are known to occur on the native OS, or an be demonstrated not to be as a result of running on VMware.
If a problem is a known Oracle issue, Oracle support will recommend the appropriate solution on the native OS.  If that solution does not work in the VMware virtualized environment, the customer will be referred to VMware for support.   When the customer can demonstrate that the Oracle solution does not work when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required.
If the problem is determined not to be a known Oracle issue, we will refer the customer to VMware for support.   When the customer can demonstrate that the issue occurs when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required.
NOTE:  Oracle has not certified any of its products on VMware.  For Oracle RAC, Oracle will only accept Service Requests as described in this note on Oracle RAC 11.2.0.2 and later releases.”
So we’ve had that ‘Not Certified” statement come up in this, so refer to FUD #3. Let’s break this down.
The above is very clear. Oracle support will recommend an appropriate solution on the native OS for any known issues. This makes perfect sense and as VMware does not modify the native OS this is absolutely fine.
If the solution does not work in a VMware virtualized environment the customer will be referred to VMware for support. This is perfectly understandable and acceptable. If there is a problem with the VMware software then VMware will need to support it, I’ll discuss the VMware extended support policy below.
If the problem is an unknown issue then the customer will be referred to VMware Support and when it’s demonstrated to be an issue on the native OS Oracle will resume support. Again this is perfectly understandable. If the problem is with VMware software that VMware should fix it. However VMware does not modify the OS therefore the problem if it’s not directly related to the VMware vSphere software will is being experienced and would be experienced by the native OS.
So the above means for any Oracle problems with the Oracle software Oracle will support you. End of story. You potentially have to prove it’s an Oracle software problem, but that is no different to the system being run on a native OS. If it’s an unknown problem to Oracle they may ask you to reproduce on a different hardware platform.
If the above isn’t enough to satisfy you that you are supported when running on a VMware vSphere platform and on a supported and certified OS then the VMware Extended Support Policy should. Under the VMware Extended Support Policy for Oracle Databases VMware Technical Support will take total ownership of any Oracle Database problems reported to them, as well as providing access to a team of Oracle DBA resources, and working with Oracle support until resolution.
I have to say that the Oracle Support team is world class and I’ve always had a good experience dealing with them. I have had the same world class experience when dealing with VMware Global Support Services, and especially the Oracle Technical Support Engineers.
In addition to the above it wouldn’t do any harm to get Oracle to confirm in writing that your environment will be supported.  Oracle backed down after they knew a customer of mine was serious and put in writing that they would fully support the environment in accordance with the terms of the contractual obligations and their support policy.  So now there is absolutely no ambiguity about the situation. It is supported, end of story.
Key Questions to Ask Oracle to Fight the FUD
Where does it say in my OLSA, which is our legally binding contract, that I must purchase licenses over and above the licenses I require for all of the CPU cores or Sockets where the Oracle Software is running and/or installed?
Where does it say in the OLSA, which is our legally binding contract, that I am not able to run on a subset of cluster hosts provided I can prove where the Oracle Software is installed and/or running in accordance with the contracted terms and conditions?
How is licensing a complete cluster with the required number of hosts any different from licensing the required number of standalone native physical servers?
Does Oracle Certify the underlying hardware platforms below the OS that run Oracle software such as IBM, HP or Dell servers?
Given that you don’t certify below the OS why would running a fully certified and supported OS on top of VMware vSphere be unsupported or be any different from a support perspective than running on native given that VMware does not modify the OS?
I have added two more items to this list of FUD in another article called Return of the FUD – Oracle Licensing on VMware vSphere.
I hope this article has been some help and has empowered you to stand up for your rights under your legally binding contracts. You can find more commentary from Jeff Browning and Dave Welch at the following locations: Oracle Storage Guy – Dave Welch of House of Brick on Oracle on VMware Licensing, Comments by Dave Welch of House of Brick on Oracle on VMware Licensing and Oracle Licensing on VMware – Reprise.
Read Certification of an Oracle ULA Agreement (or: Need to defuse a time bomb). It will help you understand where you might end up during an Oracle audit / certification process and how to use the process to your best advantage and avoid some traps. Follow this up with this article by the same authors – The impartial objective of Oracle’s compliance auditors: A 5 Million Dollar target.
A great reference for Oracle Licensing and Support has been written and published by VMware titled Understanding Oracle Certification, Support and Licensing for VMware Environments.   Some of what I’m about to describe is covered in this document and I would definitely recommend you read it.
Maybe a reason Oracle appears to be trying to perpetuate these myths around licensing and support is because the traditional Unix hardware business and Solaris is on a major downward trend. See IT Candor’s Server Market Report for the details.
For guidance and ides for design and architecture for your Oracle Databases on vSphere here are two great articles. Deploying Enterprise Oracle Databases on vSphere, Blueprint for Successful Large Scale Oracle Virtualization on vSphere.
For additional information on virtualizing Oracle visit my Oracle Page.
 
—————-
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.
Now for some good news. With this new feature and also vSphere Replication now being built into the base hypervisor you can more easily take advantage of 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. This can be used for maintenance or DR testing. You could also use this during a hardware upgrade process where you wanted to keep the old hardware in place for a short period. Just another example of how VMware vSphere allows you to increase your return on investment from your Oracle Licensing.
Final Word!
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.