The VMware question, taken apart: what the two page partitioning policy actually is, the hard versus soft sorting that favors Oracle's own technologies, how one 8 vCPU VM becomes a $7.6M claim, and the five move containment playbook. The same database, four architectures: $7.6M, $1.52M, $760K, or $380K.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
A taught session with three knowledge checks: the approved hard partitioning list, the 10 host cluster claim priced live ($7.6M from one VM), and the audit letter posture question. It closes with the same database priced across four architectures, a 95 percent spread decided entirely before any negotiation.
The full narration of this session, section by section, for reading and reference.
Welcome back, session four of forty. This is the one I've been promising since day one. Twice now I've said the words soft partitioning and told you to hold the thought, in session two when we counted physical servers, in session three's trap list. Today we open it up. Virtualization and partitioning. The VMware question. How one database, on one modest virtual machine, becomes a claim against every core in your datacenter. This is, by a wide margin, the biggest number in most Oracle audits, and here's the thing that makes it a teachable topic rather than just a scary one: the entire claim rests on a two page document you never signed, and the containment playbook is concrete, architectural, and proven. Three knowledge checks, one of them prices a real cluster claim live. Thirty minutes. Let's take on the monster.
Five things you'll walk away with. One, you'll be able to read the partitioning policy for what it is, know exactly what it says, and, more importantly, its precise contractual weight, which is a number very close to zero with an asterisk we'll spend time on. Two, you'll sort partitioning technologies from memory, which ones Oracle accepts as limiting your license count, and which ones don't, and you'll notice a suspicious pattern in that list. Three, you'll size your own exposure, we'll run Oracle's math on a realistic cluster and you can rerun it on yours tonight. Four, you'll get the containment playbook, five moves that shrink the claim by eighty to ninety five percent, by design. And five, posture. How to hold the line when this claim actually arrives, because it's a negotiation, not a bill, and the estates that know that pay a fraction. Here's the scale of what we're dealing with.
Four numbers to frame the session. Two. That's how many pages long the partitioning policy is. Two pages, on oracle dot com, anchoring the largest audit claims in enterprise software. You never signed it, your contract almost certainly never mentions it, and it can be revised by Oracle whenever they like. All. That's how many hosts Oracle's soft partitioning position counts, everywhere the virtual machine could run, not where it does run, not where it has run, where it could. Shared storage plus live migration equals could, and could equals licensed, in their reading. Three to five x. That's how far initial audit claims typically run above what independent challenge shows is actually owed. Hold that ratio in your head every time you see an audit number in this course, the opening claim is a bid, not a bill. And ten days. The one narrow exception, the failover rule from session two, one genuinely passive node, ten separate days a year. Everything else in a virtualized estate is licensed in full, under their reading. And floating over this entire session, the question from session one, the discipline this course is built on: which signed document says so? Keep asking it. Today is the session where that question earns its keep.
The partitioning policy, what it is and what it is not. What it says, first, fairly. The document sorts server partitioning technologies into two buckets, hard and soft. Approved hard partitioning technologies genuinely cap the cores you must license, carve a big server into a small licensed piece, and Oracle accepts the piece. Soft partitioning, everything else, limits nothing, if the technology could give the software more cores, you license all the cores it could reach. What it is: a two page policy paper, published on Oracle's website, revisable at any time, and, this detail is delicious, expressly labeled as being for educational purposes. What it is not: a contract term. Go look, tonight, at your master agreement and your ordering documents. The word partitioning, in this sense, almost certainly appears nowhere. The policy binds nothing and nobody. So why does it run the industry? Because of what it is commercially. Oracle's auditors apply it as if it were law. The claims built on it are enormous. And very few customers have the stomach to litigate the question, so it has never been truly tested. Its power is commercial, not legal. Understanding that distinction precisely, not dismissively, is the foundation of every move we make today.
The sorting itself, the list that decides millions. Bucket one, approved hard partitioning. Oracle VM and Oracle Linux Virtualization Manager, with CPU pinning configured. Solaris capped zones. IBM's LPAR. Configure these correctly and you license only the pinned or capped cores, a real, recognized cap. Bucket two, soft partitioning. VMware. Hyper-V. Essentially every non Oracle hypervisor on earth. No configuration of these, however airtight, limits anything in Oracle's reading. Bucket three, worth keeping separate in your head, physical separation. Dedicated servers or dedicated clusters that run only Oracle. No partitioning argument needed at all, you license the hardware, cleanly, and nobody disputes the boundary. And bucket four, the clouds, OCI and the authorized cloud environments, which have their own published counting rules entirely, sessions twenty six and twenty nine. Now step back and look at bucket one again. Oracle's hypervisor. Oracle's Linux virtualization. Sun's operating system, which Oracle owns. IBM's LPAR, the one non Oracle entry, from a platform where Oracle sells a lot of database. The technologies Oracle approves are overwhelmingly Oracle's own. That is not a technical judgment about isolation quality, VMware's pinning is technically excellent. It is a commercial position wearing a technical costume. Let's test whether the sorting stuck.
Knowledge check one. Which of these does Oracle accept as hard partitioning, actually limiting the cores you must license? A, VMware CPU affinity rules pinning the VM to two specific hosts. B, Solaris capped zones. C, vSphere DRS host groups with strict admission control. Or D, Hyper-V with virtual processor limits. Pause here. And remember whose technologies made the approved list.
The answer is B, Solaris capped zones, and only B. Every VMware construct on that list, affinity rules, DRS host groups, admission control, all of it sits in soft partitioning under the policy, no matter how technically bulletproof the configuration is. Hyper-V, same bucket. And I want to be precise about why this matters, because the wrong answers here aren't random, they're the actual arguments infrastructure teams make in real audits. We pinned it to two hosts. The DRS rules are strict. It can't migrate. All true, technically. All irrelevant, under the policy, because the policy's sorting isn't about what your configuration prevents, it's about whose technology does the preventing. That asymmetry is the tell we discussed. And it has a hard practical consequence you should tattoo somewhere: VMware containment cannot be achieved with hypervisor settings. Not with any checkbox, any rule, any affinity. Containment on VMware is built with architecture, physical boundaries, and where you have leverage, contract language. Which is exactly where this session is headed. But first, let's see how bad the uncontained position gets.
The VMware position, mechanically, and how the claim inflates. The opening position: license where the VM could run. Your database VM lives in a cluster with shared storage and vMotion, so it could run on any host in that cluster, so every core of every host counts, times the core factor, times the price list. That's the base claim. Then the escalation, and this is where modern vSphere hurts you. On current versions, storage vMotion and cross cluster migration mean Oracle has argued reach across clusters, and in aggressive cases, across an entire vCenter connected by shared storage. The whole datacenter, in scope, from one VM. The evidence fight, when it comes, runs on your own logs. vMotion histories, DRS records, datastore mappings, they become the record of where the database could and did go, and your architecture documentation becomes the counter evidence of what was genuinely impossible. And then the reality, which is where you should anchor. This is an aggressive reading of an unsigned two page policy. It has never been definitively settled in court. And in practice it resolves commercially, in negotiation, at a fraction of the opening claim, when, and only when, the customer comes prepared. Unprepared customers pay the arithmetic. Let's run that arithmetic, so you never forget its size.
Knowledge check two, and this is the one to remember. One Oracle Enterprise Edition database, on one virtual machine with eight vCPUs, sitting in a ten host vSphere cluster, thirty two Intel cores per host. What does Oracle's opening position claim? A, four processor licenses, for the eight vCPUs. B, sixteen licenses, for one host. C, one hundred sixty licenses, for all three hundred twenty cores in the cluster. Or D, nothing extra, because DRS rules pin the VM to two hosts. Pause. Where it could run, not where it does.
The answer is C, and let's feel the full weight of it. Ten hosts, thirty two cores each, three hundred twenty cores. Times the point five factor, one hundred sixty processor licenses. Times forty seven and a half thousand, seven point six million dollars. At list. Before options, and remember session three, if that database runs Diagnostics and Partitioning, those multiply across the hundred sixty too. Before twenty two percent support, another one point six million a year. From a database using eight vCPUs, a workload that fits comfortably on half of one host. Now the wrong answers, each instructive. A, four licenses for the vCPUs, is what a reasonable person would assume, and it's precisely the assumption the policy exists to destroy. B, one host, is the boundary people think affinity buys them. And D applies session two's counting to the wrong bucket, DRS pinning is soft partitioning, it moves the claim by exactly zero dollars. Eight vCPUs of actual workload, seven point six million of claimed exposure. That ratio, roughly a thousand to one between what you use and what they claim, is why this session exists, and why the next slide is the most actionable one in the course so far.
The containment playbook, five moves, in order of strength. Move one, dedicate. A separate cluster that runs Oracle and only Oracle, sized to the minimum viable host count. This is the single strongest move in Oracle licensing, full stop. It replaces an arguable boundary with a physical one. Move two, isolate. The dedicated cluster gets its own vCenter, or at minimum a hard separation, its own shared storage with no datastore visibility to the general estate, and no live migration path in or out. The isolation is only as strong as its weakest bridge, and audits go looking for bridges. Move three, document. Architecture diagrams, storage zoning configs, network separation, all dated, all filed. In the evidence fight from slide eight, this folder is your side. What you can prove could not happen is the boundary you actually have. Move four, contract. Where a renewal or a big purchase gives you leverage, write the scope into the ordering document, a clause recognizing the dedicated cluster as the licensed boundary beats the policy argument forever, it's signed paper against an unsigned PDF. Buyers with leverage get this more often than you'd think, they just have to ask. And move five, consider the platform question, hard partitioning technologies or cloud counting where the estate justifies it. Run the numbers: a dedicated two host cluster turns our seven point six million claim into thirty two licenses, one and a half million, an eighty percent reduction, achieved with hardware you probably already own. Architecture is the discount.
Four neighboring rules that complete today's picture. First, the ten day rule, restated precisely now that you can appreciate the precision. One passive failover node, in the same cluster arrangement, that only mounts the database when production actually fails, unlicensed for up to ten separate days per year. Separate days, not a rolling window. And continuous replication never qualifies, a synced standby is a running database, session two's answer, unchanged. Second, the authorized cloud environments, AWS, Azure, Google Cloud. Oracle publishes separate counting for them: two vCPUs equal one processor license when hyperthreading is on. Different rulebook entirely, session twenty nine works it in detail, today just know the seam exists. Third, OCI, Oracle's own cloud, which counts in OCPUs and ECPUs with BYOL conversion rules that are, surprise, deliberately friendlier than everything we did today. That asymmetry, hostile counting on VMware, generous counting on OCI, is not an accident, it's a sales instrument, and module six covers how to use it rather than be used by it. And fourth, the estate view. Most enterprises run all three worlds simultaneously, on premises virtualized, hyperscaler, and maybe OCI, and every audit loves the seams where a workload moved between worlds and the counting rules changed under it. Map your seams before they do.
The five virtualization traps, where cluster findings are actually born. Trap one, the quiet migration. Infrastructure moves your carefully contained database VM into the general cluster during a maintenance window, ninety minutes, then moves it back. The vMotion log records it forever, and the audit claims the whole general cluster from that one visit. Containment includes the maintenance procedures. Trap two, the template estate. VM templates with Oracle software baked in, cloned across clusters by automation. Installed counts, running or not, session two's rule, and templates are installs. Audit scripts find them all. Trap three, the shared storage bridge. A dedicated cluster that still mounts a datastore from the general estate. That one line in the datastore list is the bridge that kills the whole isolation argument. Storage separation is not optional decoration, it is the argument. Trap four, the DR mirror. Your recovery site reproduces production's cluster reach, so the claim doubles, and as we've now said three times, the ten day rule rescues none of it, because the standby is running. And trap five, the comfortable myth. We have affinity rules, so we're fine. You now know exactly why that sentence is worth zero dollars. Say it in a meeting after this course and you owe me a rewatch of knowledge check one. Alright. The letter arrives. Final check, let's set your posture.
Knowledge check three. The letter has arrived. Oracle's audit team claims your entire vCenter is in scope for your one database VM, citing the partitioning policy, and the number has a lot of zeros. What is the strongest opening response? A, pay at list, the policy is the policy. B, ask which signed contract term the claim rests on, and present your documented isolation evidence. C, ignore the letter entirely, the policy isn't a contract so the claim is meaningless. Or D, immediately migrate everything off VMware before responding. Pause. This is session one's question, under real pressure.
The answer is B, and notice it's two moves in one. First, make Oracle anchor the claim in signed language. Which clause of which document we both signed produces this number? The policy is not an answer to that question, and forcing that conversation reframes the claim as what it is, an opening negotiating position. Second, put your evidence on the table, the diagrams, the storage zoning, the dated architecture file you built on move three of the playbook. That's what actually shrinks scope, claim by claim, host by host. Now the wrong answers, because each one is a real failure mode. A pays a three to five x opening bid without a word of pushback, it happens constantly, usually driven by panic and a deadline. C mistakes a weak legal position for no position, Oracle's audit clause is real, you did sign that, and stonewalling escalates the matter while burning the goodwill you'll want in the settlement. And D, the panic migration, destroys your calm, costs a fortune, and mid audit can even look like evidence tampering. The estates that do well here are boringly consistent: they engage, they anchor on contract, they present evidence, and they negotiate the resolution, usually into a forward looking deal at a fraction of the claim. Module five choreographs all of it. Today, the posture is set. Let's close the loop with the full pricing picture.
One database, four architectures, everything this module has taught you on a single screen. Architecture one, the general cluster under Oracle's position. Three hundred twenty cores, one hundred sixty licenses, seven point six million dollars at list. That's the opening claim, the number the letter quotes. Architecture two, the dedicated two host Oracle cluster, the playbook's first move. Sixty four cores, thirty two licenses, one and a half million. Eighty percent smaller, and the boundary is physical, documented, defensible. Architecture three, right size the hardware itself, session two's discipline. A properly sized physical pair, thirty two cores total, sixteen licenses, seven hundred sixty thousand. Ninety percent below the claim. And architecture four, apply the metric decision, four hundred known users, Named User Plus, three hundred eighty thousand. Ninety five percent below where we started. Same database. Same workload. Same users. Seven point six million, or three hundred eighty thousand, and every step between those numbers came from sessions two, three, and four, counting discipline, option governance, and architecture. Nothing in that journey required a discount, a negotiation, or Oracle's permission. This is the foundation module's closing argument: the biggest savings in Oracle licensing happen before anyone talks to Oracle.
Session four, three sentences. One, the partitioning policy is a two page unsigned paper, its hard versus soft sorting conspicuously favors Oracle's own technologies, and its power over you is commercial, not contractual, real, but negotiable. Two, under the soft partitioning position one VM can put an entire estate in scope and no VMware setting changes that, containment is dedicated architecture, genuine isolation, and dated evidence. Three, the claims open at three to five x and resolve by negotiation, so the estate that built its boundary before the letter arrives is the estate that decides the outcome. And that completes module one's foundation: you can count, you know what you're counting, and you know where the count explodes. Next session finishes the module with the technology estate beyond the database, WebLogic and middleware, the software that ships underneath other software, gets installed by application teams who never think about licensing, and quietly builds the same kind of exposure. Shorter session, lighter arithmetic, one genuinely sneaky trap. See you in session five.
Homework, about an hour, and this week it's reconnaissance on your own datacenter. One, map the clusters. For every Oracle database running on a VM, which cluster is it in, how many hosts, how many cores per host. Infrastructure has this in vCenter, it's a ten minute export. Two, run Oracle's math. Total cluster cores, times point five. Write that number down and sit with it, that is the opening claim you are currently exposed to, today, as things stand. Three, check the storage. Ask the specific question: do the Oracle VMs share datastores or migration paths with the general estate? The answer is the difference between a boundary and a bridge. Four, price the alternative. What would a minimum dedicated cluster cost in hardware for those workloads? Put that number next to the exposure number from step two. That comparison usually writes its own business case, and it's the one slide your CFO will actually enjoy. And five, file the diagrams. Current architecture, dated, saved with session two's pricing drill and session three's feature usage export. Three sessions of homework, and you've quietly built the evidence file that most companies start assembling the week the audit letter lands. You're building it on a calm Tuesday instead. That's the whole game.
Five reads, all free on redress compliance dot com. First, cracking the per core VMware licensing model, today's cluster calculations worked across more scenarios and estate shapes. Second, hard partitioning done properly, if you're considering the approved technologies route, this is how the cap is configured so it actually holds in an audit. Third, hidden Oracle audit risks, the virtualization findings in context with everything else we've covered. Fourth, challenging Oracle audit findings, how cluster scope claims specifically get contested, and which evidence moves them, it pairs directly with today's playbook. And fifth, how Oracle selects audit targets, which explains, among other things, why heavily virtualized estates sit high on the list, useful for calibrating your own urgency. That's session four, and that's nearly the whole foundation module. You can count, you know the price list, and you know where the explosion risk lives and how to contain it. Session five closes the module with middleware, then module two takes everything you've built and walks it into the contracts. See you there.