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:
- Oracle Changes its Position on x86 Hypervisor Support (Unfair Licensing Remains) (May 2009)
- Oracle Honors its New Year’s Resolution: Non-Oracle x86 Hypervisors are Now Supported (May 2009)
- A New Year’s Resolution for Oracle (December 2008)
- Oracle and the Big Elephant (August 2008)
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?