How does Oracle treat Hyper V and KVM for licensing?
Oracle treats Hyper V and KVM as soft partitioning under its partitioning policy, the same category it applies to VMware, so its policy refuses to let those software boundaries limit how many processors must be licensed. To Oracle, any hypervisor whose boundaries are set in software falls into the soft category, and the policy then asserts that every host a virtual machine could reach must be licensed. Hyper V and KVM are not special cases. They sit alongside VMware in the policy that drives the largest virtualization findings.
This means organisations that moved to Hyper V or KVM expecting different treatment find the same exposure they would have faced on VMware. The hypervisor changed, the policy did not. A few Oracle virtual machines on a large Hyper V or KVM cluster can still produce a demand to license every core, multiplied by the core factor table. The full landscape is set out in the Oracle virtualization licensing guide.
Switching hypervisor does not switch the policy. Hyper V and KVM are soft partitioning to Oracle, so the cluster wide claim follows. The defense is the same one that works for VMware, anchored in your contract rather than the policy.
Why is the Hyper V and KVM claim the same as VMware?
The Hyper V and KVM claim is the same as the VMware claim because all three rest on the identical logic: soft partitioning plus virtual machine mobility equals a demand to license the whole cluster. Oracle argues that because a virtual machine can migrate across hosts, every physical host is a place Oracle could run, so every core must be licensed. The reasoning does not depend on which hypervisor you chose. It depends only on the soft partitioning classification, which applies to all of them.
The collection scripts behave the same way too. They can sweep the entire virtualization layer and report every core as if Oracle were deployed across it, regardless of where the software actually ran. Running those scripts is a decision, not an obligation, and submitting raw output concedes the cluster wide premise. The mechanics are identical to those described in why VMware is not hard partitioning to Oracle, which is why the defense transfers directly.
| Hypervisor | Policy classification | Resulting claim |
|---|---|---|
| VMware | Soft partitioning | Whole cluster |
| Hyper V | Soft partitioning | Whole cluster |
| KVM, standard | Soft partitioning | Whole cluster |
| Listed hard methods | Hard partitioning | Bounded to the partition |
Why is the partitioning policy not the contract?
The partitioning policy is not the contract because it is a separate document Oracle publishes and revises on its own, and in most agreements it is not incorporated as a binding term of the signed Oracle Master Agreement. Where a policy paper conflicts with the contract, the contract governs. This is the foundation of every soft partitioning dispute, whether the hypervisor is VMware, Hyper V, or KVM, and it is why the buyer move begins with reading the agreement.
Auditors will present the partitioning policy as a rule you accepted. Usually you did not. The agreement defines the licensed programs, the metrics, and the obligations, and it rarely states that a soft partitioning hypervisor requires licensing every host in a cluster. When the contract is silent, the policy cannot manufacture that obligation. The same reasoning underpins the broader cluster dispute in disputing cluster wide virtualization claims.
When can KVM be hard partitioning?
KVM can be hard partitioning only in the specific configurations Oracle lists in its policy, which require following the exact method Oracle defines rather than a general KVM deployment. Oracle recognises certain engineered and processor level approaches as hard, and some Oracle Linux virtualization configurations can qualify when set up precisely as the policy specifies. A standard KVM cluster, configured the way most teams run it, does not meet those conditions and is treated as soft partitioning.
The lesson is that qualifying for hard partitioning is exacting and documented, not incidental. If you intend to rely on a hard partitioning configuration to bound your licensing, the setup must match Oracle's defined method exactly, and you must be able to evidence it. Whether your specific configuration qualifies is contract and configuration dependent, which is one reason these positions are best tested before an audit rather than during one.
Whether the partitioning policy binds you, and whether a KVM configuration qualifies as hard, is contract and configuration dependent. The dispute always begins by reading your specific agreement and inspecting the real setup, not by assuming the general position.
How do you defend a Hyper V or KVM finding?
You defend a Hyper V or KVM finding the same way you defend a VMware finding, by anchoring to your contract, declining to accept the soft partitioning classification as obligation, and reconciling the claim to the hosts that actually ran Oracle. The contract argument removes the policy foundation, and the technical reconciliation narrows the claim from the whole cluster to the relevant hosts. Both are pressed together, calmly and in writing, through a single channel.
- Confirm whether your agreement incorporates the partitioning policy
- Where it does not, decline the cluster wide premise as a policy position
- Map actual Oracle installation and runtime to specific hosts
- Document host affinity, segregation, or dedicated clusters that bounded mobility
- Reconcile the script output to documented deployment, not topology
A worked example
Consider an anonymized utility running Oracle on five hosts within a thirty six host Hyper V cluster. Oracle's opening finding applied the soft partitioning classification and claimed every host in the cluster.
| Stage | Position |
|---|---|
| Opening finding, all 36 hosts under the policy | $7.9M |
| After contract anchoring and host reconciliation | $1.8M |
The agreement did not incorporate the partitioning policy, and the five Oracle hosts ran in a documented, segregated cluster with affinity rules. Reconciled to those hosts, the defended position fell roughly 77 percent, within the 60 to 80 percent range a line by line review typically achieves. This example is illustrative and anonymized, and outcomes depend on your estate, your contract and your evidence.
Your next step
Hyper V and KVM carry the same cluster wide exposure as VMware and the same disputability, because the claim rests on policy rather than contract. An independent buyer side review tests the policy against your specific agreement and reconciles the claim to real deployment. Our advisors work on a Fixed Fee or Gainshare basis with no risk to you, and we reduce your Oracle exposure or we reimburse our service fee.
Read the Oracle virtualization licensing guide for the full partitioning policy versus contract distinction across every hypervisor, then test it against your own cluster.