Size the refresh before you quote it.
Feed in RVTools data or manual cluster numbers, configure each cluster's target hosts, and get a sized build: host specs, host counts, per-core licensing math, and a customer-ready report — in the browser, with nothing uploaded.
How it works
1๏ธโฃ Load demand
Drop an RVTools export (.xlsx) and it rolls up vCPU, vRAM, and storage demand per cluster โ or type cluster numbers in manually, or try the demo environment.
2๏ธโฃ Configure each cluster
The mid-step: per-cluster target host specs, platform presets, growth headroom, CPU/RAM overcommit, N+1/N+2, and HCI storage. Live host-count previews as you tune.
3๏ธโฃ Get the build plan
Worked sizing math per cluster, a bill-of-materials summary, per-core licensing with phantom-core waste, SE talking points, and a downloadable HTML briefing report.
What it reads from RVTools
| Tab | What it unlocks |
|---|---|
vInfo | VM inventory per cluster: allocated vCPUs, configured RAM, provisioned/used storage โ the only required tab |
vHost | Current host count, sockets/cores, CPU & memory utilization โ unlocks "actual utilization" sizing basis and current-state licensing |
vCluster | Cluster membership and datacenter rollup |
vDatastore | Storage demand fallback when vInfo storage is incomplete |
Same tolerant parser as RVTools Analyzer โ modern and legacy column names both work, missing tabs degrade gracefully. No export handy? Manual entry takes cluster-level totals, which is all the math needs.
Sizing math, explained
For each cluster, demand is computed from your chosen basis (allocated resources or actual utilization from the export), then divided by usable per-host capacity:
cpu hosts = ceil( demand vCPU รท (host cores ร cpu overcommit ร (1 โ growth)) )
ghz hosts = ceil( demand vCPU ร ghz/vCPU รท (host cores ร base clock ร (1 โ growth)) )
mem hosts = ceil( demand vRAM รท (host RAM ร ram overcommit ร (1 โ growth)) )
build hosts = max(cpu hosts, ghz hosts, mem hosts, storage hosts) + redundancy spares
The GHz dimension checks your clock assumptions against the silicon: demand assumes a sustained GHz per vCPU (tunable, default 0.5), and each host contributes its physical clocks (cores ร base clock of the selected Xeon 6 SKU โ no overcommit, since overcommit is already expressed in the vCPU ratio). If the GHz count wins, your overcommit is promising more sustained clock than the cores deliver. The binding constraint (CPU, GHz, RAM, or storage) is called out explicitly per cluster โ that's usually where the presales conversation lives. Worked example:
| Step | Numbers | Result |
|---|---|---|
| Demand (allocated) | 400 vCPU ยท 3.2 TB RAM ยท 20% growth | โ |
| Target host | 2ร 32c Xeon 6745P @ 3.1 GHz ยท 1 TB RAM ยท 4:1 CPU / 1.25:1 RAM overcommit | โ |
| Usable CPU/host | 64 ร 4 ร 0.8 | 204.8 vCPU |
| Usable RAM/host | 1024 ร 1.25 ร 0.8 | 1024 GB |
| Usable GHz/host | 64 ร 3.1 ร 0.8 | 158.7 GHz |
| CPU hosts | ceil(400 รท 204.8) | 2 |
| RAM hosts | ceil(3276.8 รท 1024) | 4 โ binding |
| GHz hosts | ceil(400 ร 0.5 รท 158.7) | 2 |
| Build (N+1) | max(2, 4, 2) + 1 spare | 5 hosts |
That cluster is memory-bound โ the SE takeaway: spec more RAM per host (or a denser platform) before adding boxes. Every cluster in the tool shows this worked math with your numbers plugged in.
Honest limitations
- This is capacity sizing, not performance sizing. It doesn't model IOPS, latency, NUMA boundaries, or noisy-neighbor effects โ validate the final spec against performance data.
- Utilization from RVTools is point-in-time, not an average. "Actual utilization" basis inherits that caveat.
- Overcommit ratios are your professional judgment, not measurements โ the defaults (4:1 CPU, 1.25:1 RAM) are common starting points, not recommendations.
- Licensing covers vSphere compute cores only (per-core, 16-core minimum per socket). vSAN capacity entitlements, NSX, Aria, and Windows Server licensing aren't modeled.
- No pricing โ BOM is host counts and specs, which your VAR tooling turns into quotes.
Frequently asked questions
Is my data uploaded anywhere?
No. Files are read with the browser's FileReader API and parsed in memory by a vendored copy of SheetJS running in this page; manual entries never leave the form. There is no server and no network request carrying your data โ check devtools' network tab, or disconnect after the page loads.
Is anything stored in my browser?
Only if you use the Projects feature: named projects and the autosaved session live in localStorage on this machine only โ never uploaded. Everything else lives in the page's JavaScript memory for the session. Hit "Clear session data" or close the tab and the in-memory analysis is gone.
Do I need an RVTools export, or can I type numbers in?
Either. The export gives you per-cluster demand automatically (plus utilization and current-state licensing). Manual entry just needs cluster-level totals: VMs, vCPUs, RAM, storage, and optionally current hosts โ five minutes with the customer's capacity spreadsheet.
What's the "configure each cluster" step for?
Refreshes are never one-size-fits-all: the VDI cluster wants dense hosts, the database cluster wants RAM, the ROBO site wants N+2. The mid-step lets you set target host specs, growth, overcommit, redundancy, and HCI storage per cluster before the final math runs โ with a live host-count preview as you tune.
Why does it model GHz as well as vCPUs?
Because vCPU count alone hides clock speed: a 128-core 2.0 GHz host and a 32-core 3.5 GHz host look very different to clock-sensitive workloads. Each target CPU is a real Intel Xeon 6 SKU with its published base clock (turbo ignored โ sustained sizing). The tool checks your assumed sustained GHz per vCPU against the physical clocks per host; when GHz sets the host count, your overcommit ratio is promising more clock than the silicon delivers โ pick a higher-clock SKU or ease off the overcommit.
Can I share the results with my team or the customer?
Yes โ the Build plan tab generates a standalone HTML briefing you can download and email. Fully self-contained, no external dependencies, and it contains only the analysis, which you control. Scrub customer names from cluster labels first if the report leaves your org.
Does it replace a real capacity assessment?
No โ it's a first-pass sizing from inventory and point-in-time utilization. It can't see performance history or workload behavior, so treat outputs as the starting point for the real assessment, not the verdict.
How does licensing math work?
Broadcom licenses vSphere per physical core with a 16-core minimum per socket: license cores = sockets ร max(cores per socket, 16). The tool applies this to your target host spec, rolls it up across the build, and compares against current-state cores when vHost data is present. vSAN, NSX, and Aria aren't modeled.
Can I use it on a customer site with no internet?
Yes. Once the page has loaded, everything โ including the spreadsheet parser โ runs locally.
Why does it ask about overcommit instead of measuring it?
Because safe overcommit is a judgment call that depends on workload behavior the tool can't see (CPU-ready, memory pressure, growth). It gives you the sliders with sane defaults and shows exactly how they move the host count, so the assumption is explicit instead of buried.
Does it do pricing?
No โ it produces host counts, per-host specs, and license-core counts. Your VAR quoting tooling turns that BOM into dollars.