Oracle licensing on Hyper-V: why the cluster sets the cost.

Oracle classifies Hyper-V as soft partitioning, so you license every physical core in every host the database could be scheduled onto. Containing that cost is an architecture decision about the cluster and its migration paths, and the contract plays a smaller part.

This guide is for infrastructure and procurement leaders running Oracle Database or Oracle middleware on Microsoft Hyper-V in 2026. It covers how Oracle decides which hosts count, what a typical cluster costs at list price, when a failover node is actually free, and how to build and document a cluster that holds up in an audit.

Read it alongside our Oracle partitioning policy guide, the virtualized environments licensing guide and the Oracle Knowledge Hub. The rules below come from Oracle's own documents: the Oracle Partitioning Policy, the Processor Core Factor Table, Licensing Data Recovery Environments, the Oracle Technology Global Price List and the Oracle Database Licensing Information manual.

How does Oracle count licenses on Hyper-V?

Oracle counts the physical cores in every host the Oracle virtual machine could run on, then applies the core factor. The virtual processors you assign in Hyper-V Manager play no part. Hyper-V sits in Oracle's soft partitioning category, so any limit you set inside Windows or the hypervisor is ignored for licensing purposes.

Why does Oracle treat Hyper-V as soft partitioning?

Oracle's list of approved hard partitioning technologies is closed, and Hyper-V is not on it and never has been. The list names physical domains, capped Solaris containers, capped IBM partitions, and Oracle's own hypervisors configured with Oracle's own CPU pinning method. Microsoft's hypervisor appears nowhere in that set.

Oracle's stated reason is that an administrator can reverse a hypervisor level limit. Whether you find that persuasive makes no difference in an audit. The auditor checks the technology against the list, and that is the whole test.

Do Hyper-V CPU groups change the count?

No. CPU groups are the strongest technical argument buyers bring, so it is worth being precise about why they fail. A host CPU group pins a virtual machine's virtual processors to a defined set of logical processors at the hypervisor level, which is a firmer control than a simple virtual processor cap.

It is still absent from Oracle's list. Oracle does not run a technical assessment of how firm your restriction is. It checks a name against a document, and when the name is missing, the answer is every core in the migration domain.

Which Hyper-V hosts do you have to license?

You license every host the Oracle virtual machine can reach. In a Windows Server Failover Cluster with Cluster Shared Volumes, that is normally every node, because CSV presents the storage to all of them at once.

• Single standalone host with no migration path. License the cores in that host only.
• Failover cluster with CSV. License every node in the cluster, including nodes that have never hosted the database.
• Two standalone hosts on a shared network. Both are in scope if shared nothing live migration is enabled between them.
• Host group managed by System Center. Oracle will ask for the host group topology, because Virtual Machine Manager orchestrates migration across it.
• Anti affinity, preferred owner and possible owner settings. Useful for operations, but any cluster administrator can change them, so they do not form a licensing boundary.

How does shared nothing live migration widen the scope?

Since Windows Server 2012, Hyper-V can live migrate a running virtual machine between two hosts with no cluster and no shared storage, using only a network connection. Many companies that believe their Oracle host stands alone are in fact running one half of a migration pair.

Auditors now check for this. A current review asks whether live migration is enabled on each host, which networks it uses and which hosts it is constrained to. For virtual machines outside a cluster, the setting is "Enable incoming and outgoing live migrations" under Live Migrations in Hyper-V Settings, so check it on every host and record the result.

How does the Core Factor Table apply on Hyper-V?

Multiply the physical cores in scope by the factor Oracle assigns to the processor. Most current x86 parts carry 0.5, so a 32 core host needs 16 Processor licenses before any cluster arithmetic starts. Hyperthreading makes no difference on your own hardware, and our core factor reference lists the exceptions that matter.

Why is Oracle on Azure counted differently from your own Hyper-V hosts?

Azure is one of the public clouds Oracle names as an Authorized Cloud Environment, and there Oracle counts virtual CPUs. Two Azure vCPUs equal one Processor license with multithreading enabled, and one vCPU equals one license without it. Your own Hyper-V hosts get physical core counting, even though Azure runs on Microsoft's hypervisor.

The same soft partitioning rule applies the same way on Nutanix AHV and on VMware, and our white paper on Oracle and VMware licensing covers the vSphere version in detail. If you are considering leaving the data center, read the Oracle cloud licensing policy and how bring your own license works before you size anything.

What does Oracle on a Hyper-V cluster cost?

Enterprise Edition lists at $47,500 per Processor, and support adds 22 percent of the license fee every year. On a shared cluster of current dual socket hosts that reaches millions of dollars before any options, and because support recurs, the gap between a contained design and a shared one grows every year you carry it.

How do you work out the count for a four node cluster?

Take four failover cluster nodes, each with two sockets of 24 cores. That gives 48 physical cores per node and 192 across the cluster.

1. Cores in scope. 4 nodes multiplied by 48 cores equals 192.
2. Core factor. 192 multiplied by 0.5 equals 96 Processor licenses.
3. Enterprise Edition at list. 96 multiplied by $47,500 equals $4,560,000.
4. Annual support at 22 percent. $1,003,200, and Oracle raises it at every renewal.

Compare the second row with the third. Both are dedicated two node clusters with the same resilience model and the same operating pattern. The only difference is the processor part number, and it is worth $1.52M at list plus $334,400 in support every year.

How does the bill change between a small shop and a large Hyper-V farm?

The rule is identical at every size, but where the exposure comes from is different. Two hypothetical companies show the range.

• Two standalone hosts with 16 cores each. Shared nothing live migration is enabled between them, so Oracle counts 32 cores: 16 Processor licenses and $760,000 at list. Disable migration on the Oracle host, prove it, and the count falls to 16 cores, 8 licenses and $380,000.
• A 20 node shared farm with 48 cores per node. If Oracle virtual machines can reach every node, Oracle counts 960 cores. That is 480 Processor licenses, $22,800,000 at list and $5,016,000 a year in support.

For the small company, the exposure usually sits in one forgotten host setting. For the large one, it sits in the original decision to place Oracle inside the general virtualization cluster.

When does Named User Plus cost less than Processor licensing?

Named User Plus carries a minimum of 25 users per Processor license, and that minimum follows the same core count. On the 16 Processor design in the table, the floor is 400 users at $950 each, or $380,000, half the Processor price. On the shared four node cluster, the floor rises to 2,400 named users.

The break even sits around 50 named users per Processor license, since $47,500 divided by $950 is 50. Below that, count your users carefully and check whether an application front end forces you to count every downstream user; above it, Processor licensing costs less. Our crossover calculator runs the comparison on your numbers.

On Hyper-V, Oracle sizes the bill by how far a live migration can carry the database. Shrink that reach and the license count shrinks with it.

What does Windows Server add on the same hosts?

Windows Server Datacenter is also licensed per physical core, with a minimum of 16 cores per server and 8 per processor. A dense Oracle node is therefore charged twice, once by Oracle and once by Microsoft. Model both vendors on the same node design, in the same spreadsheet, before you sign the hardware order.

At roughly $6,000 to $7,000 per 16 core pack at open list, a 48 core node carries about $18,000 to $21,000 of Datacenter licensing before Oracle counts anything. Microsoft's current suggested price for a Windows Server 2025 Datacenter 16 core pack is $6,771, or $20,313 for three packs.

Is the failover node in a Hyper-V cluster free?

Usually not. Oracle publishes a narrow failover allowance, and almost every Hyper-V cluster we review has been read more generously than Oracle wrote it.

What does Oracle's failover allowance permit?

• One node at a time. A single unlicensed node may take over from the licensed node. Oracle states that only one failover node per clustered environment is free, even if several are configured for failover.
• One cluster, one storage array. The nodes must sit in the same cluster and share one logical disk array in a single data center. A stretched design across two arrays falls outside the allowance.
• 10 days in total per year. The allowance is ten separate 24 hour periods per calendar year, and every failover event in that year draws on the same ten.
• Maintenance counts. Oracle's document says downtime for maintenance counts toward the ten periods, so every patching window spent on the spare node uses up allowance.
• Day eleven. Once you pass the allowance, the node must be fully licensed. Oracle does not bill only the excess days.
• Switching back. Once the primary node is repaired, Oracle expects you to move the database back or make the repaired server the failover node. Leaving it running on the spare indefinitely is not covered.

The conditions are set out in Oracle's Licensing Data Recovery Environments document. Compare them with your actual failover history from the cluster logs before you assume the standby node costs nothing.

Which standby, disaster recovery and backup servers need a license?

A warm standby running Data Guard is fully licensed from day one, because the database is installed and running. A cold server holding only backup files, with no Oracle software running, needs no license until it is used.

The middle case is where the money goes. A DR cluster that is powered on, patched monthly and tested periodically is not cold, and an auditor will treat it as production. Oracle does allow a backup copy to be tested on an unlicensed server four times a year, two days at most each time.

Does a Hyper-V Replica host need an Oracle license?

Treat it as licensable and confirm your position before you build it. Hyper-V Replica copies a virtual machine to a secondary host and keeps it ready to start, so the replica host holds installed Oracle software on disk. Oracle's rule for standby and remote mirroring is that every program installed or running must be licensed.

What have we seen in recent Oracle on Hyper-V reviews?

Across roughly 20 to 30 Oracle virtualization reviews I handled in 2024 and 2025, Hyper-V exposure almost always came from cluster design rather than from the licensing rules themselves. Four patterns kept repeating.

• Shared clusters cost far more. Putting Oracle in a shared cluster produced a license gap of 2x to 5x against an isolated Oracle host design.
• Migration scope was undocumented. In 60 to 80 percent of the environments we reviewed, there was no record of which hosts the Oracle virtual machines were allowed to reach.
• Virtual processor caps were offered as a defense. Buyers raised them in roughly 1 in 3 cases, and Oracle rejected the argument every time.
• The failover node was assumed free. Around half the companies assumed so. Under Oracle's own failover terms, most of them were wrong.

Which mistakes cost Hyper-V buyers the most?

• Placing Oracle in the shared cluster during a migration. A temporary placement still counts. If an auditor finds the database ran there, every node in that cluster enters the claim.
• Answering Oracle's questions before mapping the hosts. Once you have described your environment to Oracle, correcting the description is harder than getting it right the first time.
• Calling a DR site cold when it is patched and tested. Monthly patching and regular failover tests turn the site into licensable infrastructure.
• Refreshing hardware without recounting. A new server generation with more cores per socket raises the Oracle count even when the node count stays the same.

How do you contain Oracle licensing on Hyper-V?

Make the physical boundary small, permanent and easy for an outsider to verify. That is an architecture decision first and a contract question second, and four changes deliver most of the saving.

Should you isolate the Oracle hosts?

Yes, and isolate them completely. A dedicated Hyper-V cluster for Oracle workloads, with its own hosts, its own storage and no migration path outward, is the only design Oracle reviewers consistently accept as a boundary.

Half measures do not survive review. If Oracle stays in the shared cluster behind preferred owner settings, you are back at the full node count as soon as an auditor asks what enforces them. Our dedicated cluster design guide sets out the same approach for vSphere.

Why does the processor choice matter more than the cluster size?

Oracle bills by the core, so the part number is the most valuable decision in the whole design. A 16 core part on an Oracle node costs a third of a 48 core part for the same node count.

• Size the Oracle nodes for the database load you run today and leave consolidation headroom to the general cluster.
• Prefer parts with a higher clock speed and fewer cores, which usually suit Oracle workloads anyway.
• Keep the general virtualization cluster dense and the Oracle cluster sparse, because Microsoft and Oracle reward core density in opposite directions.
• Revisit the design at every hardware refresh, because a like for like refresh often doubles the core count without anyone noticing.

Could Standard Edition 2 cut the cost?

Sometimes, and it is dismissed too quickly. Standard Edition 2 is licensed per socket at $17,500, so a two node cluster of two socket hosts is four sockets and $70,000, against $760,000 for Enterprise Edition on the dedicated 16 core design.

The limits are real. SE2 requires servers with a maximum of two sockets, caps a single database at 16 CPU threads, and excludes Partitioning, Advanced Compression, and the Diagnostics and Tuning Packs. Check each workload against those limits before you plan a migration, using our Standard Edition 2 licensing guide for the detail.

Why we would not spend effort perfecting virtual processor caps

The standard advice is to cap virtual processors, set anti affinity rules, document the intent and hope the auditor accepts it. We disagree, because that advice misreads what Oracle is testing. Oracle is checking whether the technology appears on a closed list, and Hyper-V does not, so better enforcement cannot change the answer.

Every hour spent perfecting a soft control is an hour not spent placing the database on hardware with a real boundary. Buy the smallest Oracle cluster that meets the workload, disable outward live migration, prove it with storage zoning, and treat every hypervisor setting as an operational convenience.

What is the fair case for documented soft controls?

They still carry weight in a negotiation. Documented controls shift the discussion from Oracle's opening claim across the whole environment to a factual argument about where the database actually ran, and that argument settles materially lower. Use them to reduce a settlement, and do not mistake them for a licensing defense.

How do you prove where your Oracle virtual machines can run?

With dated configuration exports, stored outside the cluster, that show the migration scope as it stood during the period Oracle is reviewing. In our experience an accurate position without records settles worse than a weaker position that is well documented.

1. Export failover cluster node membership from PowerShell, with processor detail, and date stamp the output.
2. Capture the live migration configuration on every host, including whether it is enabled and which networks it uses.
3. Capture storage zoning and LUN masking showing that Oracle volumes are not presented to unlicensed hosts.
4. Export the System Center host group topology if System Center manages your hosts.
5. Record processor model, socket count and physical core count per host, with the core factor applied.
6. Pull DBA_FEATURE_USAGE_STATISTICS on every instance so option usage does not surprise you later.

Which commands and consoles produce that evidence?

Everything on the list comes from tools your Windows and storage teams already run. The table maps each item to its source.

What will Oracle's auditors say about Hyper-V, and how should you answer?

Expect the same few lines in almost every Hyper-V review. Each has a factual reply, provided the evidence above already exists.

• "Hyper-V is soft partitioning, so every host you run is in scope." Accept the classification and dispute the scope. Show which hosts the Oracle virtual machines can reach, with cluster membership, migration settings and storage zoning.
• "Your standby node is licensable." Reply with the failover history and each condition: one node, one cluster, one array, and fewer than ten 24 hour periods in the calendar year, maintenance included.
• "Virtual Machine Manager can place the database on any host in the host group." Show that the Oracle hosts form their own cluster, that their storage is zoned away from other hosts, and that outward live migration is disabled.
• "Please run our data collection scripts on all servers." Limit the request to the hosts in the Oracle migration domain and review the output before it leaves your hands. Our analysis of Oracle's audit scripts explains what they collect.
• "The partitioning policy settles this." Ask Oracle to show how the Processor definition in your ordering document, applied to your deployment, produces the count it claims.

Is Oracle's partitioning policy binding on you?

No, and that cuts both ways. The document states on its face that it is provided for educational purposes and is not incorporated into any agreement, so neither side can point at it and declare the matter closed.

What does that mean when Oracle makes a claim?

Oracle has to argue that your ordering document's definition of Processor, read against your deployment, produces the cluster count. That position is open to challenge, and the challenge starts with a close reading of the Processor definition and any server or location restrictions in your own order.

What does that mean when you defend?

You cannot use the policy's non contractual status as a shield while relying on the same document's approved list when it suits you. Pick one reading and hold it consistently, because auditors notice when a customer switches.

How do these disputes settle in practice?

Most settle on the evidence. The buyer with dated proof of a bounded migration domain settles low, and the buyer arguing about the policy's status without evidence settles high, whichever reading of the document is technically correct.

What should you ask for in the ordering document?

Oracle rarely changes its standard terms for a single order, but a large Processor purchase is the moment to ask. These requests matter most on Hyper-V.

• A named host schedule. List the servers or cluster the Processor licenses cover, so the licensed boundary is written into the contract.
• Written treatment of replica and DR hosts. A sentence on how a Hyper-V Replica target or a periodically tested DR site is licensed removes the most common later dispute.
• Audit scope and frequency. The standard clause allows an audit on 45 days written notice. Ask to limit reviews to one per 12 months and to the programs on the order.
• A price hold on additional Processors. A hardware refresh or a new node adds licenses, and a held unit price keeps that purchase from reopening the discount.

What to do next

1. Map the reach. List every Hyper-V host the Oracle virtual machines can migrate to today, including through shared nothing live migration and System Center host groups.
2. Count and compare. Count the physical cores in that domain and apply the core factor. That is Oracle's opening number, so have it first, then compare it with the Processor quantity on your ordering documents and write down the gap in dollars.
3. Test the failover node. Pull your actual failover history and check it against the ten day allowance before you assume the standby node is free.
4. Choose what to isolate. Decide which workloads justify a dedicated, isolated Oracle cluster on low core count processors.
5. Close the paths. Reconfigure storage zoning so Oracle volumes are visible only to licensed hosts, and disable outward live migration.
6. Record it. Export the evidence set the same week you make the change, and put the export on a quarterly schedule with a named owner.
7. Recount. Recount Processor licenses against the contained boundary, and test Standard Edition 2 for every database that fits its limits.
8. Prepare before you talk to Oracle. Bring an independent benchmark and a reading of your contract into the room before any true up conversation.

Frequently asked questions