How to use the Nutanix Conversation Sizer

1. What this is and when to open it

The sizer turns a VM estate into an honest node count range during a live conversation: raw-to-usable storage math, the Controller VM (CVM) tax paid up front, realistic ceilings, and a failure reserve, in about sixty seconds of typing. It is for the architect or seller running the conversation, in front of the Customer or preparing for one.

Open it when you hear:

1. "Roughly how many nodes would our environment need?"
2. "What do we really get out of 30 terabytes raw?"
3. "Why does everyone say Nutanix eats resources for its storage controller?"
4. "Can you ballpark this before we run the formal sizing?"

Two disciplines are built in and cannot be turned off: it quotes ranges, never single numbers, and it says on every output that Nutanix Sizer is the source of truth. This tool gets the conversation within roughly 25 percent; Sizer produces the number that goes in a contract.

2. The front door: what are you sizing?

The tool opens by asking what you are sizing. Nine workload patterns from the field guide (general virtualization, VDI, database, files, objects, Kubernetes, ROBO and edge, DR target, backup repository), plus three example Customers you can walk in as. Picking a pattern lands you on a starting point with every assumption stated, cited to the guide, and flagged where you must verify it with the Customer before quoting the range out loud.

From the landing you choose the depth: See the answer jumps straight to the node range, Open every dial drops you into the full manual surface with all fifteen inputs live, and Start over wipes everything back to the front door. The manual surface is always one click away and nothing about it changed; the patterns just decide where the dials start.

The three example Customers (Beacon Ridge Credit Union, Cardinal Freight Systems, Meridian Health Network) are fake companies carrying real-magnitude estates anchored to the guide's small, medium, and large reference architectures, each with a variable-by-variable explanation of what every number means and what it drives. They double as the best way to learn the tool.

Prefer the blank sheet? The front door has a skip link that opens every dial at the defaults, exactly the tool as it always was.

Or skip typing entirely. The front door accepts a Nutanix Collector or RVTools .xlsx export, dropped or picked. The file is parsed in your browser and never leaves the machine. The sizer reads powered-on VMs (templates, SRM placeholders, and rows Collector marks not for sizing are excluded and itemized), averages vCPU and RAM, and sums consumed storage into decimal TB. Every derived number lands on the same starting point panel with its basis stated, flagged for verification, and adjustable. The file says what exists, not what it does: workload pattern and growth stay yours to set.

3. The inputs, in the order that matters

Workload pattern first. Normally the front door already set this. Inside the tool the quick dropdown carries the three most common patterns (general virtualization, VDI, database) and each pattern sets four things at once: the vCPU-to-physical-core ratio, compression and dedup expectations, and the CVM profile. Patterns are honest starting points, not answers; every value stays editable after you pick one.

The estate. VM count, average vCPU, average RAM, used storage in TB. Averages are fine here; that is what a conversation-grade estimate means. If the Customer has RVTools-style actuals, even better, type those.

Growth. Annual percent and the sizing window, default 24 months. The guide's rule: size for 18 to 24 months of growth, then plan to add nodes. Sizing for five years buys idle hardware; sizing for today fills the cluster the day the growth arrives.

Data protection. RF2, RF3, or erasure coding. This is the biggest storage lever in the tool:

1. First, the mechanism: RF2 keeps two full copies of every write and RF3 keeps three, while erasure coding stripes data with parity blocks instead of full copies, which is why its usable percentage is higher.
2. RF2: 50 percent of raw is usable, tolerates one node failure, three-node minimum. The default answer for most estates.
3. RF3: 33 percent usable, tolerates two simultaneous failures, five-node minimum. Storing a third copy means the same data needs about 50 percent more raw capacity than RF2 (equivalently, a third less usable per raw TB), so make the Customer earn it: what are the actual RTO and RPO requirements, and what does the backup layer already cover?
4. EC-X 4+1 and 4+2: 80 and 67 percent usable, for cold and archival data, with six and seven node minimums. Not for hot latency-sensitive workloads.

The CVM profile. Light (8 vCPU / 32 GB), Standard (12 / 48), Heavy (16 / 64). The Controller VM is the storage controller running on every node, and the tool subtracts it from usable resources before a single guest VM lands. When a competitor calls it overhead, the honest answer is yes, and here it is with numbers.

The node profile. Cores, RAM, raw TB per node. The default is a middle-of-the-road box (32 cores, 768 GB, 30.72 TB raw). Type the actual hardware model under discussion for a sharper range. Two more defaults an architect may probe: the platform capacity reservation is set to 12 percent (the guide says 10 to 15), and the honest-range band is 25 percent, both editable in the formula cards.

The ratios. Compression, dedup, and vCPU-to-pCPU. The efficiency defaults come from the guide's planning ranges (and the guide is blunt: never quote marketing 4 to 6x compression). The overcommit ratios are field heuristics, 4:1 general and 2:1 database, labeled as such because the guide deliberately publishes none.

4. How the range is built (the whole chain is on the page)

1. Growth compounds the estate over the window.
2. Raw becomes usable: the RF multiplier, minus the 10 to 15 percent platform reservation.
3. Usable becomes effective: times the 75 percent storage ceiling (snapshots live inside that headroom), times compression, times dedup.
4. Three gates compute independently: nodes by CPU (after the CVM vCPU tax and the 70 percent ceiling), nodes by RAM (after CVM RAM and the 80 percent ceiling), nodes by storage.
5. The biggest gate wins, the failure reserve is added (N+1 for RF2, N+2 for RF3), and the result clamps to the RF minimum node count.
6. The honest ceiling: floor times 1.25, because the guide says these heuristics land within roughly 25 percent, so a range is the only honest quote.

Every step renders as a formula card with algebra, your numbers substituted live, the assumptions, and a source link to the exact appendix that justifies it. The summary bar pins the range, the binding gate, effective TB per node, and storage demand while you scroll.

5. The four outputs and what to do with each

1. The answer. One sentence: "This estate fits in roughly N to M nodes of this profile at RF2," with the binding gate named. Say it out loud exactly as written, range and all.
2. The whiteboard card. Five lines built to be copied onto an actual whiteboard: estate, range, effective per node, CVM tax, and the pre-sizer disclaimer. The copy button gives you plain text.
3. The conversation script. Five quotable lines in the field guide's voice: why ranges, how to frame RF2 versus RF3, the CVM honesty line, the data-efficiency expectation reset, and the headroom defense. These exist so the hard questions get answered the same way every time, well.
4. The next action. The formal handoff: run Nutanix Sizer with real workload data, what to collect before that meeting (per-VM actuals, peak IOPS, RPO and RTO per tier, growth targets), and the risk areas to say out loud.

6. Three conversation plays

1. The ballpark ask. "Just roughly, what would we need?" Type the four estate numbers, read the answer sentence, then screenshot the whiteboard card into the follow-up email. Total elapsed time: under two minutes, and nothing you said tonight contradicts what Sizer says next week, because you quoted a range.
2. The CVM objection. A competitor said the storage controller eats the cluster. Open the CPU gate formula card and show the subtraction happening: 12 vCPUs and 48 GB per node, taken off the top, in the math. Honest numbers beat defensive talking points.
3. The RF3 reflex. Customer insists everything needs RF3 because more copies sounds safer. Flip the selector from RF2 to RF3 in front of them and let the node range jump. Then ask the script's question: what RTO and RPO actually require surviving two simultaneous node failures? Usually the answer is a tier, not the whole estate.

7. Limits, stated plainly

1. This is a pre-sizer estimate within roughly 25 percent, for conversations. Nutanix Sizer with real workload data produces proposals.
2. The overcommit ratios are field heuristics; the guide publishes none. Edit them to your own beliefs.
3. The CVM table derives from public documentation and should be re-validated against current portal specs for a design.
4. Compression and dedup are planning ranges until a POC measures them on the Customer's actual data.
5. Peak IOPS, latency targets, and network design are Sizer-and-architect territory, not this tool's.

Every formula sources the public field guide: appendix F, sizing rules. Also see the TokenOps manual.