Oracle treats Microsoft Hyper V, Nutanix AHV and KVM the same way it treats VMware, as soft partitioning that does not limit scope. The hypervisor under your Oracle estate rarely changes the rule. Isolation and a proven boundary are what decide the count at a ULA certification, in either direction.
By the Meridian advisory team, former Oracle LMS and GLAS licensing analysts. Updated 4 June 2026.
Oracle treats Microsoft Hyper V as soft partitioning, which it does not accept as a way to limit licensing scope. That is the same stance Oracle takes on VMware, Nutanix AHV and most KVM builds. The label matters because Oracle recognises only a short list of hard partitioning technologies, and everything outside that list is, in Oracle's position, no boundary at all. So the question buyers often ask, whether moving off VMware to Hyper V or another hypervisor changes the count, has a blunt answer in most cases: it does not. What changes the count is isolation and the boundary you can prove, not the brand of the hypervisor.
Oracle scopes virtualization by where a product can run, not by which hypervisor runs it. Soft partitioning, whether VMware, Hyper V, AHV or KVM, does not contain scope. Hard isolation and documented boundaries do, and the same rule that creates exposure can build entitlement at certification.
Hard partitioning, in Oracle's framing, is a physical or firmware level method that pins Oracle workloads to a fixed set of processors that cannot expand. The technologies Oracle has historically recognised are narrow and hardware bound. They include Oracle VM Server configured with CPU pinning, Oracle Linux KVM with hard partitioning enabled through the official Oracle process, certain physical domains on engineered and SPARC systems, and IBM LPAR within stated limits. Microsoft Hyper V is not on that list. Nutanix AHV is not on that list. Generic KVM, outside Oracle's own hard partitioning configuration, is not on that list. This is why a hypervisor migration alone, for example consolidating from VMware onto Hyper V, does not by itself shrink scope. You move from one soft partitioning platform to another and Oracle's counting position is unchanged.
Oracle's own virtualization can qualify as hard partitioning, but only when configured exactly to Oracle's documented method, with CPUs pinned and the configuration evidenced. Running Oracle VM without the pinning, or pinning it loosely, leaves you back in soft partitioning territory. The configuration is the entitlement, so the evidence file has to capture it.
These are treated as soft partitioning. Where the Oracle product can run on any host the cluster can reach, Oracle's position is that every processor in reach is in scope. Live migration, clustering and shared storage extend that reach, exactly as they do under VMware. The defence is not the platform, it is the boundary.
Because almost every common hypervisor is soft partitioning in Oracle's view, the variable that actually moves the count is reach. The question is always the same: on how many physical processors could the named Oracle product run, by current configuration and by live migration? Every processor inside that reach is, in Oracle's position, in scope. A dedicated three node cluster that runs Oracle and nothing else, with migration locked to those three nodes, scopes to those three nodes. The same workload free to migrate across a forty node estate scopes to forty nodes. The hypervisor is identical in both cases. The boundary is what differs, and the boundary is what you can engineer and prove.
This is why the work at certification is identical across platforms. Map where Oracle can run, control the migration boundaries, and document the limit. The same discipline that defends against an over broad sweep in an audit lets you decide, deliberately, which hosts to count when maximization is the goal. The mechanics behind the sweep are set out in when a whole cluster counts, and the arithmetic across mixed platforms is worked through in the virtualization counting worked example.
Take an indicative estate. An organisation runs Oracle Database on a cluster of six hosts, two processors each, with a core factor of 0.5. The hypervisor underneath is the variable, the workload and the cluster are constant. The point of the comparison is that the platform does not move the number; the boundary does. All figures are indicative and the real scope depends on configuration and contract language.
| Configuration | Oracle partitioning view | Processors in scope |
|---|---|---|
| VMware, free migration across 6 hosts | Soft, whole cluster | 12 cores × 0.5 = 6 |
| Hyper V, free migration across 6 hosts | Soft, whole cluster | 12 cores × 0.5 = 6 |
| Nutanix AHV, free migration across 6 hosts | Soft, whole cluster | 12 cores × 0.5 = 6 |
| Any hypervisor, isolated to 2 dedicated hosts | Boundary proven | 4 cores × 0.5 = 2 |
| Oracle VM with CPU pinning, documented | Hard partitioning recognised | Pinned cores only |
The first three rows are the same number because the partitioning view is the same. Only the last two rows move it, and both move it through isolation rather than through the choice of platform. In a defensive setting the isolated rows limit exposure. In a maximization setting, where the capacity is genuinely used, the larger in scope number can be counted toward certification at no marginal cost, because support stays flat and certification carries no fee.
The controls that work are platform agnostic, because they all attack reach rather than the hypervisor itself.
Run Oracle on a defined set of hosts or a dedicated cluster that runs Oracle and nothing that would expand scope. The smaller and cleaner the host set, the smaller the in scope number you have to either defend or count.
Prevent live migration from carrying Oracle virtual machines onto hosts outside the dedicated set. An unconstrained migration policy quietly expands scope across every host the cluster can reach, and Oracle will count that reach.
For Oracle VM or Oracle Linux KVM hard partitioning, capture the pinning configuration as it stood inside the term. For soft partitioning platforms, capture the cluster membership, the migration settings, and the dates. The evidence file is what converts a configuration into a defensible position, and it is the same file that defends the certified count in an audit afterwards.
The lesson for any ULA holder weighing a hypervisor decision before exit is that the platform is rarely the lever. Hyper V, Nutanix AHV and KVM sit in the same soft partitioning bucket as VMware, and only Oracle's recognised hard partitioning methods, configured and evidenced, change that. Everything else comes down to where Oracle could run and whether you can prove the boundary. Decide that deliberately, host by host, and the count follows. The full method, with the rest of the virtualization cluster, lives in our pillar, the ULA exit strategy guide.
Oracle treats Hyper V, Nutanix AHV and generic KVM as soft partitioning, just like VMware, so switching hypervisors does not shrink your ULA scope. Only recognised hard partitioning, configured exactly and documented, or hard isolation that limits where Oracle can run, changes the count. Map the reach, lock the migration boundary, and prove the limit. The platform is not the lever. The boundary is.
Oracle treats Microsoft Hyper V as soft partitioning, which it does not accept as a way to limit licensing scope. The same applies to VMware, Nutanix AHV and KVM. Only a short list of hard partitioning technologies is recognised, and Oracle VM can qualify when configured with hard partitioning through pinned CPUs.
Isolation is the control that works across every hypervisor. Run Oracle on dedicated hosts or clusters, prevent live migration into non Oracle hardware, and document the boundary. Where Oracle could run is what Oracle counts, so a proven boundary limits the count regardless of which hypervisor sits underneath.
Book a confidential assessment and we will map where Oracle can run across your virtual estate so you can isolate to limit risk or count to build entitlement.