Code as Idea
The other pages here turn code into something to look at. This one turns a question into something to change. A what-if earns its place by naming what would settle it — so every scenario below carries the published fact it collides with, the instrument that would decide it, and an honest label on whether anything has actually been run — including, often, that this lab cannot run it at all.
Why most what-ifs are expensive
An interactive figure answers three different kinds of question at three very different costs, and the kind decides whether a conversation can explore it live:
- Knob — the author exposed it. Change it in the browser, instantly.
- Rebuild — a constant in the model. One edit, then a rebuild measured in milliseconds.
- Re-author — new parts, or a different shape of machine. A long build session.
Most interesting what-ifs are the third kind. The useful discipline is to decide, before drawing anything, which questions become knobs — because those are the only ones anyone will ever actually ask twice.
Architecture
Failure-domain questions. This lab has no Nutanix cluster of its own and never deploys NC2 for internal testing, so each card says plainly whether the lab can settle the question or only reason about it.
-
What happens when a host dies?
- Our read
- Data resilience and VM availability are two different guarantees, and most arguments about host failure are really an argument about which of the two the speaker means. Separating them is the figure's whole job.
- What would settle it
- Not settled by this lab: there is no AHV cluster here and NC2 is never deployed for internal testing. It is settled by the documented recovery sequence, with every assumption labelled, or on borrowed hardware.
- Source
- CloudLab Works lab discussion, 2026-10-11
-
What if this site lost WAN — what must keep working locally?
- Our read
- The question nobody answers honestly until the link is actually down, because the dependency you forgot is never on the diagram.
- What would settle it
- This lab can run it, and it is the one scenario here where a home lab is the better instrument than a document: pull the uplink and enumerate what survives. No spend.
- Source
- CloudLab Works lab discussion, 2026-10-11
- Figure
- Not published yet — Fig 2 - not published yet
-
What if inference moved beside the data instead of sending data to the model?
- Our read
- The interesting measure is where the bytes travel and what leaves the building, not how fast the answer comes back.
- What would settle it
- Partly testable here: send the same request to a local model and to a hosted one and compare where the data travels. Performance claims are out of scope; they would not generalise.
- Source
- CloudLab Works lab discussion, 2026-10-11
- Figure
- Open the interactive figure — Fig 1 - how an agent request becomes work; knobs: local vs cloud, tool fails, retry budget
-
What if we lost a host during maintenance — where are the hidden dependencies?
- Our read
- Failure during a planned operation is a different domain than failure at rest: capacity is already reduced when the unplanned one lands. Two faults at once is the case most designs are never walked through.
- What would settle it
- Not settled by this lab. The pattern can be reasoned against documented rolling-upgrade behaviour; the measurement needs a cluster this lab does not have.
- Source
- CloudLab Works lab discussion, 2026-10-11
-
What if the cloud disappeared for an hour?
- Our read
- Two questions wearing one coat: what keeps serving, and what can still be changed when the console is gone. The second one is usually the surprise.
- What would settle it
- Testable here: cut external reachability and record what still answers and what can no longer be administered. No spend.
- Source
- CloudLab Works lab discussion, 2026-10-11
- Figure
- Open the interactive figure — Fig 4 - control plane vs data plane; vendor-neutral by construction
NC2
Three assumptions worth checking before a design review. Each card separates what Nutanix reports from what we read into it, and says how the source was checked — the two limits cards quote the public NC2 on AWS guide, and the third quotes a Nutanix blog post. Verify against the current guide for your version. No measurement here is ours.
-
What if the resume takes longer than the outage you hibernated for?
- Reported — source opened and checked
- Nutanix states that NC2 preserves cluster data and metadata by backing it up to Amazon S3 while the bare metal nodes are shut down, and positions hibernation for clusters that are not in use — test and development environments idle at weekends, or disaster recovery where recovery point objectives are a day or more.
- Our read
- Hibernation is sold on the saving, and the saving is easy to compute. The resume clock is the part nobody computes, and an RPO measured in days is a strong hint that the round trip is not quick. Treat the restore duration as the number that decides whether hibernation fits, and get it from the current product documentation rather than from a blog post or from us.
- What would settle it
- Needs no cluster and no spend: take the published restore rate for your AOS version, apply it to your dataset, and compare the result against the recovery target. The arithmetic fails the plan before any cluster exists.
- Source
- nutanix.com/blog/hibernate-and-resume-feature-now-av…
- Figure
- Open the interactive figure — Fig 3 - the hydrate clock, computed from your own numbers
-
What if we shrink to two nodes to ride out a squeeze?
- Reported — source opened and checked
- The public NC2 on AWS Deployment and User Guide (Cloud Clusters (NC2) Hosted, October 8, 2026), Getting Started With NC2 > Limitations, states: "Two-node clusters are not supported." and, on the single-node case, "NC2 does not recommend using single-node clusters in production environments."
- Our read
- On-premises habits about small clusters do not carry over. If this holds, the floor is a refusal rather than a tradeoff, which makes it the wrong lever to reach for under cost pressure — and the kind of constraint worth finding before the design review, not during it.
- What would settle it
- Confirm against the current NC2 on AWS guide for your AOS and NC2 version before relying on it. No spend, and no cluster required.
- Source
- download.nutanix.com/documentation/hosted/Nutanix-Cl…
- Figure
- Open the interactive figure — Fig 5 - the floor is a refusal, not a tradeoff
-
What if we sized for the maximum node count and the region cannot hold it?
- Reported — source opened and checked
- The public NC2 on AWS Deployment and User Guide (Cloud Clusters (NC2) Hosted, October 8, 2026), Getting Started With NC2 > Limitations, states: "A maximum of 28 nodes are supported in a cluster. NC2 supports 28-node cluster deployment in AWS regions that have seven placement groups."
- Our read
- If the ceiling depends on how many placement groups a region offers, then it is a property of geography rather than of the product, and a design that is valid in one region is not automatically valid in another. That belongs in the drawing as a visible part, not in a footnote.
- What would settle it
- Check the target region against the current NC2 on AWS guide before the topology is drawn. No spend, no cluster.
- Source
- download.nutanix.com/documentation/hosted/Nutanix-Cl…
- Figure
- Open the interactive figure — Fig 5 - the ceiling moves with the region
States read proposed until a test has actually run here, and evidence is labelled STATED until there is a result to point at. A scenario that cannot name its instrument is not on this page.