Jeff Stonacek, Principal Architect
The theme of this blog is, “it’s complicated”. PowerVM is not necessarily complicated to the point where it is difficult to understand, but is complicated compared to other hypervisors when it comes to Oracle licensing. PowerVM is IBM’s virtualization hypervisor for Power architecture. There are a lot more knobs to turn with PowerVM than there are on x86 platforms, like VMware. With VMware, a virtual machine is configured with a number of virtual CPUs. But with PowerVM, there are several parameters that guide the hypervisor on how many physical processors can be used, and in what fraction (down to 0.01 fraction of a core for newer PowerVM micro-partitions).
Disclaimer: This is not a PowerVM deep dive, but rather a summary explanation of PowerVM related to Oracle licensing.
PowerVM Overview
The following Oracle licensing related nomenclature are associated with PowerVM:
- Frame – term used to describe a physical server
- Processor Pool – sub-divided processors from the frame, dedicated to the pool
- Logical Partition (LPAR) – PowerVM virtual machine
- Dedicated LPAR – LPAR built on dedicated cores, not micro-partitioned
- Micro-Partition – LPAR built on shared CPU resources
- Virtual Processor – represents a physical core to the LPAR
- Entitlement – guaranteed CPU resources for micro-partitioned LPAR
- Capped – [a capped] micro-partitioned LPAR cannot exceed its entitlement
- Live Partition Mobility (LPM) – live migration of an LPAR onto a different processor pool
Oracle Licensing Options for PowerVM
When deploying Oracle workloads on LPARs, there are two options for Oracle licensing.
- License the underlying physical hardware (AKA traditional core-based licensing)
- Use Oracle’s extra-contractual hard partitioning policy to license the LPAR
Licensing the Hardware
Licensing the underlying hardware is pretty straightforward. Count the cores where Oracle software is “installed and/or running” then apply the core factor, and that is the number of licenses that are required. However, with LPARs, there is a bit of a catch, as a frame can have multiple processor pools. As a result, LPARs can live in different pools and can potentially live migrate between pools. Processor pools typically contain a subset of the total cores on a frame, and a frame can have multiple pools. If LPARs are associated with a processor pool and configured so they never leave that pool, then the number of cores in the pool can be counted to determine licensing liability. As with any virtualization technology, if the LPARs are allowed to float around, then it gets messy and we have to count all processors where the LPARs have run.
Licensing with the Oracle Partitioning Policy
The other method for licensing LPARs is to use the guidelines described in the partitioning policy. There are many partitioning technologies outlined in the document, but from an AIX standpoint, the document outlines the following restrictions.
- Dedicated LPARs are allowed
- If using micro-partitioned LPARs, the following restrictions must be met:
– The LPAR must be capped
– LPM must be disabled
– TurboCore mode is not permitted
If using a dedicated LPAR, count the number of virtual processors towards license usage. In this case, the LPAR can use up to 100% of the number of physical processors as configured as virtual processors for the LPAR. In other words, a dedicated LPAR with two virtual processors can use up to 100% of two physical cores.
With a micro-partitioned LPAR it is more complicated, however. In order to use Oracle’s Partitioning Policy, the LPAR must be capped. In this case, you count the entitled capacity, or entitlement, towards license usage. However, the entitlement can be specified as a decimal. In which case we need to round up to count the number of processors in use. For example, a capped, micro-partitioned LPAR with two virtual processors and an entitlement of 1.4 is counted as two cores towards license usage.
Remember, with micro-partitioned LPARs, LPM must be turned off. Technically speaking, if an LPAR moves from one pool to another, it is only running on one pool at a time. From a licensing standpoint, this is considered a de-install and re-install of the license for that LPAR, incurring a licensing liability only on one pool at a time. However, since LPM must be disabled in order to take advantage of the partitioning policy, this fact doesn’t apply.
Licensing Strategy
Since there are different options for licensing on PowerVM, care should be given to licensing strategy. When licensing the hardware, use processor pools to limit the license count. Keep in mind that different pools can be configured for different Oracle products. One pool can be dedicated to Enterprise Edition only, whereas another pool may be used with Enterprise Edition plus Partitioning. No matter the strategy, make sure the LPARs don’t float around or more licenses will be consumed.
Using the Oracle partitioning policy is useful when the licensing footprint of the LPARs is smaller than that of the underlying hardware. In this case, either use dedicated LPARs or follow the guidelines for licensing micro-partitions in the Oracle partitioning policy.
The partitioning policy is especially useful when licensing rarely used Oracle features. For example, you may have a few databases that use a separately licensed feature, like Partitioning or Advanced Compression. These LPARs can be licensed using the partitioning policy, while the rest of the environment is licensed using the underlying hardware.
Summary
In this blog, I worked to make sense of some of the PowerVM intricacies related to Oracle licensing. This topic continues to come up at House of Brick as we work with clients running on PowerVM. Unraveling some of the mysteries behind the PowerVM hypervisor is critical to understanding the related Oracle licensing implications.
