Gartner Blog Network

Oracle Broadens x86 Virtualization Support, but Work Remains

by Chris Wolf  |  November 10, 2010  |  9 Comments

Today EMC’s Chad Sakac blogged about a significant update to Oracle’s support policy for VMware ESX environments – Oracle no longer explicitly excludes Oracle RAC from being virtualized. It should also be noted that Oracle’s support is limited to “issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware.” In other words, if it’s not a known bug, customers may be asked to reproduce problems on the bare metal.

Like Chad, this is an issue I have blogged about repeatedly over the last couple of years. For a historical perspective, you can read the following posts:

While Oracle should be applauded for supporting RAC in VMware environments, RAC support has not been the top customer requirement. Most Oracle customers license Oracle products by CPU core. In VMware environments, Oracle has asked customers with core-based licensing to license every physical core in an ESX cluster. The result is that customers often have to pay added licensing fees to run Oracle workloads in VMware VMs. Some clients have had to run Oracle workloads in small ESX clusters to stay within licensing compliance. Many have decided not to virtualize Oracle products until licensing restrictions were eased so that organizations would not have to pay more to run Oracle workloads in x86 VMs.

Some customers are more fortunate. For example, one client I have worked with migrated 100 Oracle database instances from AIX to RHEL/ESX last year. Their motivation was to save on IBM support costs, which they estimated at close to $200,000 annually. This particular client had a site license with Oracle, making the migration to ESX practical because they didn’t have to pay additional licensing fees to run in the ESX environment.

The root of the problem stems from the fact that Oracle considers the x86 hypervisor “soft partitioning.” Oracle’s policy on software partitioning states that “soft partitioning is not permitted as a means to determine or limit the number of software licenses required for any given server.” This rule also applies for Oracle’s own hypervisor – Oracle VM (OVM). However, Oracle makes an exception for Oracle VM, but only when VMs are pinned to physical CPU cores. That requirement complicates the execution of essential virtualization features such as live migration (vCPUs must be re-pinned to the target host’s physical cores after migration). An interesting side note in the licensing conversation is that Oracle allows licensing by vCPU for instances deployed to Amazon Web Services. Why make an exception for Amazon and not for VMware, Microsoft, Citrix, and other virtualization vendors? Our clients have repeatedly asked Oracle the same question.

Note that Oracle recently announced the availability of OVM instances hosted on EC2 instances and the licensing policy for AWS does not carry over to Oracle’s OVM hypervisor. The document “Licensing Oracle Software in the Cloud Computing Environment” describes OVM licenses on Amazon EC2 as follows:

Licensing policy for Oracle VM in EC2 environments: Amazon has implemented Oracle VM EC2 instances in accordance with the practices defined in the Oracle policy document titled, ‘Hard Partitioning with Oracle VM‘, which is referenced in Oracle’s Partitioning Policy. This ensures that a given virtual processor in an EC2 instance is assigned to a specific physical core on the backend server. From an Oracle product licensing point of view, this means that each virtual processor is equivalent to a physical core, and the standard Oracle Processor metric definition applies.

So to summarize, Amazon AWS is getting better licensing terms than Oracle even affords to its own hypervisor.

Oracle practically stands alone in its licensing policies for x86 virtualization. Both IBM and Microsoft allow software to be licensed by virtual processor, for example. Both vendors also offer broad support for a variety of x86 virtualization platforms (e.g., VMware vSphere, Microsoft Hyper-V, and Citrix XenServer). If Oracle is not in the business of certifying hardware, then why make the distinction for virtualization software? If ESX is supported, then why not XenServer, Hyper-V, or KVM? Vendors are not doing QA on every hypervisor, but they are offering “best effort” support, and there’s no reason why Oracle could not offer the same for its customers.

Finally,I think it’s also relevant to note that VMware introduced a new feature in vSphere 4.1 called DRS Virtual Machine Host Affinity. In my opinion, the feature was added primarily for the sake of satisfying Oracle licensing. DRS Host Affinity rules allow administrators to limit the physical hosts that VMs can reside on in a cluster. In theory, that should allow organizations to only license the physical hosts in a cluster where VMs running Oracle workloads are allowed to run instead of having to buy licenses for every physical core in the entire cluster. To date, Oracle does not recognize VMware’s DRS Host Affinity as a means to enforce “hard partitioning.” To me, adding additional administrative overhead for the sake of enforcing licensing compliance for one vendor should not be necessary in the first place.

Oracle should simply afford all x86 virtualization vendors the same courtesy it gives Amazon – licensing based on virtual processors and not physical processors. Like other vendors, Oracle could include end user license agreement (EULA) restrictions that do not allow multiple physical cores to be bound to a single virtual processor. Vendors include such restrictions so that customers cannot use virtualization to try and circumvent processor licensing (e.g., bind one virtual processor to multiple physical processors, while only paying for a single processor license). In fact, Oracle has a similar type of arrangement in its agreement with AWS.

Again, Oracle should get credit for expanding its support policy to include support for RAC in ESX environments. However, let’s not lose focus of the fact that Oracle’s current licensing policy often requires customers to spend more on software licensing to run an Oracle instance in a VM rather than to run the instance on a physical server or IBM LPAR. Now that cloud service providers offer VMware, Microsoft, and Citrix hypervisors, it’s hard to see how Oracle can offer Amazon favorable licensing conditions and not extend the same terms to providers that wish to run Oracle workloads on competing hypervisors.

Now is the time to lift restrictive licensing terms that favor certain partners (e.g., Amazon) and not others (e.g., VMware). The virtualization hypervisors and underlying x86 hardware have proven that they have matured to the point where they can support enterprise application workloads. I’m sure that was part of the reason why Oracle now supports RAC on ESX. However, support was never the greatest customer pain point.

Broad support is pointless if the licensing policy will not allow customers to run Oracle workloads on their hypervisor of choice. Oracle’s competitors (e.g., Microsoft, IBM, and SAP) have already shown the way to hardware-agnostic (e.g., user, instance, and virtual processor based) licensing that supports the customer’s platform of choice. It’s time for Oracle to do the same. 

What do you think?

Category: cloud-computing  server-virtualization  virtualization  

Tags: amazon  citrix  microsoft  oracle  vmware  

Chris Wolf
Research VP
6 years at Gartner
19 years IT industry

Chris Wolf is a Research Vice President for the Gartner for Technical Professionals research team. He covers server and client virtualization and private cloud computing. Read Full Bio

Thoughts on Oracle Broadens x86 Virtualization Support, but Work Remains

  1. Chris,

    I think you (and the industry) have been too good with them so far. I happen to work for VMware now but I have been screaming about this for about 10 years at my IBM tenure (yes even against IBM SWG support positions; I can tell you very funny stories and fights… maybe over a beer or two).

    I believe this is getting ridiculous. Let’s face it. The industry is celebrating because Oracle stated that now RAC is “not supported”. In fact Oracle is the only ISV that has three support policies for virtualized environments:

    1- Prohibited
    2- Not Supported
    3- Supported

    This is from Metalink (courtesy of Chad’s post) the level of “support” they provide:

    “Oracle will only provide support for issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware.”

    If the issue is known it should be documented and I am wondering why I would need to call support. If the issue is not known they will ask the customer to replicate the problem on a physical server. Period. That’s what they say. It’s not supported (at least the way I interpret it).

    But the real question that drives me up the wall is… how was life when it was “prohibited”? Was that physical punishment? I am curious.

    Well I guess I have to line up and say, thanks Oracle for relaxing your policy.


  2. Chris Wolf says:

    Thanks for weighing in, Massimo, and I understand your frustration. I’m also glad that you didn’t let IBM off the hook either. It took a serious customer push to get us to sub capacity licensing for ESX, etc.

    The reason I wrote this post today is because I didn’t think it was necessary to congratulate Oracle on satisfying a support requirement that was far down customers’ priority lists. Many customers running RAC are keeping it on the bare metal for the time being, so I didn’t see RAC + ESX as high priority. The bigger issue continues to be licensing, and it’s my hope that Oracle will hear enough about this issue from customers that a change will be warranted. I wanted to point out the discrepancy with AWS because one would assume that what’s good for AWS would be good for all.

  3. I agree on all fronts.

    Don’t get me started on the licensing thing. I had an informal chat with a local VMware customer a few days ago. He was asking the local VMware team to officially counter a statement from an Oracle sales rep that was saying that “.. not only all hosts in the cluster should be licensed… but all hosts connected to the SAN”. Whatever that means. What’s next? You need to license all servers connected to an ethernet switch (you know… just in case).

    This is just getting insane. Of course when I asked a written statement from the sales rep (with his name) everything went silent.

    If it wasn’t to protect the privacy of this customer and the fact that the email exchange was in italian…. I would have copied and pasted it over here. It would have been a fun 10 minutes for your readers.

    End of rant. Sorry, this thing usually light me up.

    Thanks for your article.


  4. Hi Chris and Massimo

    (Disclaimer, I also work for VMware)

    Do you have any real life examples on how Oracle will claim licenses for their software? Will they simply require licenses for all cores or sockets in an ESX cluster – period, or will they traverse log files to determine which hosts a VM has been running on? Here locally in Denmark, I’ve come across a customer who experienced the latter. In that case Oracle might not recognize DRS Host Affinity, but the result will still be beneficial to the customer as he can ensure that enough hosts are licensed, even though it is only a subset of all hosts in a cluster.

    Regards Henrik

  5. Chris Wolf says:

    Hi Henrik –

    I have had a variety of experiences with customers on this topic. A few have site licenses, making counting cores unnecessary. Many were asked to count cores for the entire cluster where an Oracle DB would be deployed. For those customers, most opted to not move Oracle to the ESX farm because they would have a higher licensing cost. Others deployed small clusters (e.g., 3 nodes) to keep licensing costs contained. Some very large organizations I have worked with were able to secure the license audit model you describe, but that level of support was negotiated as part of a license renewal.

  6. David Welch says:


    Thanks for the insightful post.

    I’m feeling the need to offer some clarifications:

    You wrote: “In VMware environments, Oracle has asked customers with core-based licensing to license every physical core in an ESX cluster.” You also wrote in a reply to a comment: “Many (of Chris Wolf’s customers) were asked to count cores for the entire cluster where an Oracle DB would be deployed.”

    What follows may or may not be consistent with your statements: we are also aware of some attempts by Oracle field reps beginning about two years ago where they suggested to customers that they needed to license all sockets on any given cluster of physical ESX server hosts due to the possibility that a VM hosting an Oracle workload “could” migrate to any one of the other physical servers.

    We are unaware of any legally-defensible, contract-based argument for such a position. There is no need to obtain processor-based licenses for any node where Oracle executables are not “installed and/or run”.

    The actual language in an enterprise’s OLSA rules. On topics where the OLSA is silent, the then-published language in Oracle’s public-facing Software Investment Guide (global price list) or Disaster Recovery Licensing Guide would apply.

    Oracle Price List (aka Software Investment Guide) updated Nov 2009.“software%20investment%20guide Scan for “installed and/or running” and you’ll find the quote on page 15.

    Oracle “Licensing Data Recovery Environments”, updated April 2010. Scan for “installed and/or run”.

    There is no need to license a node simply because the Oracle Home on one licensed node can “see” another node in the ESX cluster, or that someone technically “could” start or move an Oracle instance to that node. Both of those fail the clear, unambiguous “installed and/or run” language.

    You wrote:

    ‘To date, Oracle does not recognize VMware’s DRS Host Affinity as a means to enforce “hard partitioning.” To me, adding additional administrative overhead for the sake of enforcing licensing compliance for one vendor should not be necessary in the first place.’

    Per the Oracle Server/Hardware Partitioning Guide ( “Hard partitioning physically segments a server, by taking a single large server and separating it into distinct smaller systems.” VMware’s DRS Host Affinity Rules is not a feature intended or capable of partitioning within a single ESX server host.

    Please let me know if you see anything in OLSA language or any related Oracle-published documentation to the contrary.

    Dave Welch
    CTO – House of Brick Technologies

  7. Mike Timbers says:

    As a client of both companies, it is difficult to reconcile Oracle’s stance with the direction that IT is going. Any suggestion that any server that a service could possibly go to must be licenced as if it is already there makes large virtualisation farms impossibly expensive.

    If I were to buy a ten-blade chassis to virtualise five Oracle db along with my mail and file servers, I’m obliged to licence all ten blades for Oracle which *increase* my costs.

    How can virtualisation really take off if software companies cling to outmoded concepts?

  8. Mike Lorengo says:

    Hi Chris,
    So what is Oracle’s official opinion on DRS Host Affinity in 4.1 or Pinning Oracle VMs to a subset of hosts on an ESX cluster?

    Can I run Oracle RAC on 3 of 8 hosts in a cluster and use DRS to float those 2 hosts across the cluster with DRS Host Affinity?

    Can I run Oracle RAC pinning 3 nodes (1 node to each ESX Host) in the cluster?

    Oracles licensing refers to VSphere as Soft Partitioning, therefore we have to license the physical processors. Is there any Oracle document that talks to the above scnenarios besides the one referenced in this post?


  9. Chris Wolf says:

    Hi Mike,

    The answer to all of your questions is “No.” Host affinity is not recognized as a means to support “hard partitioning.” To date, Oracle has not published any updates on the subject. If/when they do, I’ll blog about the changes.

Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.