10.2 Foundation and Foundation Central: Imaging and Cluster Deployment
Key Takeaways
- Foundation is the Nutanix imaging tool that installs the hypervisor and AOS onto bare-metal nodes and forms them into a cluster.
- Foundation can run as a standalone VM, from a portable Foundation applet, or from the CVM of an existing node, and the Foundation Use Case Matrix decides which to use.
- Foundation Central extends imaging to remote sites: nodes shipped to a branch call home to Foundation Central and are imaged without an engineer travelling there.
- Foundation Central runs as a service associated with Prism Central, which is what makes zero-touch remote deployment possible.
- Foundation is a deployment tool used once per node; ongoing software and firmware updates are the job of the Life Cycle Manager instead.
10.2 Foundation and Foundation Central: Imaging and Cluster Deployment
Objective 1.3 asks you to "identify Foundation/Foundation Central use cases and features." They are two tools with one purpose — turning bare-metal servers into a working Nutanix cluster — separated by where the servers are.
Foundation: Imaging and Cluster Creation
Foundation is the Nutanix bare-metal imaging tool. Given a set of nodes with nothing useful installed, Foundation:
- Discovers the nodes on the network.
- Images each node with the chosen hypervisor and the chosen AOS version.
- Applies the network configuration — host IP, CVM IP, and out-of-band management IP for each node, plus netmask and gateway.
- Creates the cluster from the imaged nodes.
The result is a running cluster you can log into with Prism Element. This is a deployment-time activity: for most nodes it happens exactly once.
Where Foundation Runs
There is more than one way to run Foundation, and the blueprint points at the Foundation Use Case Matrix for choosing between them:
| Form | When you use it |
|---|---|
| Standalone Foundation VM | The general case. Import the Foundation VM onto a laptop or an existing host on the same network as the new nodes, and drive imaging from its web UI. |
| Foundation applet / portable Foundation | A lighter-weight option for smaller jobs where deploying a full VM is unnecessary. |
| CVM-based Foundation | Nodes that already have a CVM — for example factory-imaged nodes or nodes being re-imaged — can be imaged from the CVM of an existing node without a separate Foundation VM. |
[!TIP] The recognition point is simply that Foundation is not a single fixed artefact. If a question offers "you must always deploy a dedicated Foundation VM" as an option, it is wrong — the use case matrix exists precisely because there are several valid paths.
What Foundation Needs
- Network reachability to the nodes, typically on the same Layer 2 segment for discovery.
- The AOS and hypervisor images you intend to install.
- The IP addressing plan — three addresses per node is the usual arithmetic: host, CVM, and out-of-band management.
That last point connects to Objective 3.2, which asks about out-of-band management use cases. Foundation configures the OOB interface as part of imaging, which is what lets you manage the node later without an operating system running.
Foundation Central: Imaging Nodes You Cannot Reach
Foundation solves the problem of imaging nodes on your network. Foundation Central solves the harder problem: imaging nodes at sites where you have no Nutanix expertise and no engineer.
The scenario is the classic retail or branch rollout. A hundred stores each need a small cluster. Flying an engineer to a hundred sites is unaffordable, and store staff cannot be expected to image nodes.
Foundation Central inverts the direction of the connection:
- Foundation Central runs centrally, as a service associated with Prism Central.
- Nodes are shipped directly from the factory to the remote site.
- On-site staff perform only physical tasks: rack the nodes, connect power, connect the network.
- Each node calls home to Foundation Central using configuration supplied through DHCP options or a small amount of pre-staged information.
- Foundation Central images the nodes and forms the cluster remotely.
The operational win is that skilled work happens once, centrally, and the site work is reduced to cabling.
| Foundation | Foundation Central | |
|---|---|---|
| Runs | Locally, near the nodes | Centrally, with Prism Central |
| Connection direction | Foundation reaches out to nodes | Nodes call home to Foundation Central |
| Requires on-site expertise | Yes | No — racking and cabling only |
| Typical use | Datacenter build, single cluster | Many remote/branch sites at scale |
Foundation Is Not LCM
This distinction is worth stating explicitly because it maps onto two different blueprint objectives:
- Foundation (Objective 1.3) is a deployment tool. It creates clusters from bare metal, and it images nodes.
- Life Cycle Manager (Objective 3.3) is a maintenance tool. It performs inventory and updates AOS, AHV, firmware, and other components on a cluster that already exists, non-disruptively.
If a scenario says "the cluster is running and we need to update AHV," the answer is LCM. If it says "the nodes arrived and there is nothing on them," the answer is Foundation. A node being re-imaged — reset back to a clean state, perhaps to change hypervisor — goes back to Foundation, and the blueprint reference "Prepare Bare-Metal Nodes for Imaging" under Objective 3.2 is where that intersects hardware maintenance.
Summary
| Scenario | Tool |
|---|---|
| Build a new cluster from bare-metal nodes in your datacenter | Foundation |
| Change a node's hypervisor by re-imaging it | Foundation |
| Deploy clusters at 100 branch sites without travelling to them | Foundation Central |
| Update AOS, AHV, or firmware on a running cluster | Life Cycle Manager |
A retailer is deploying small Nutanix clusters to 120 stores. Store staff can rack and cable equipment but have no Nutanix skills, and sending engineers to every site is not affordable. Which tool fits?
Which task is performed by Foundation rather than by the Life Cycle Manager?