Scope. This article covers Nutanix Community Edition 2.1 deployed as a nested virtual machine on KVM/libvirt. It targets a single-node RF1 lab environment, not production. The installer ships AOS 6.8.1; the upgrade path to AOS 7.0 via LCM is discussed. Prism Central pc.7.5 is the version documented here.
Why These Decisions Matter
Nutanix Community Edition runs well as a nested VM on a KVM host. A single virtual machine can host the AHV hypervisor, a Controller VM, and Prism Central, giving you a complete Nutanix stack for development, training, or integration testing. The deployment itself takes a few hours.
The problem is that five of the choices you make during those hours cannot be changed afterward. On physical hardware or in a full Nutanix cluster, some of these can be adjusted. On a nested CE single-node, they cannot. Get one wrong, and the only recovery is to destroy the VM and start over.
This article documents those five decisions, the arithmetic behind the correct values, and the consequences of getting them wrong. It is based on a validated deployment that failed once on undersized disks before succeeding on the second attempt with corrected dimensions.
Decision One: Disk Sizes
The Nutanix CE installer (Phoenix) expects at least three disks: one for the hypervisor boot, one for the Controller VM, and one for data. Each disk loses approximately 60 GB to system partitions that the CVM lays down during installation. Only the remainder participates in the Stargate storage pool.
The arithmetic matters. With a 200 GB data disk, the usable pool is roughly 140 GB. With a 200 GB CVM disk, the CVM partition consumes most of it. The resulting storage pool is around 125 GB total. That is enough to run Prism Element alone, but it is not enough to deploy Prism Central, which requires a 500 GB disk in its Small configuration (the minimum on pc.7.5), and it is not enough to stage the AOS upgrade bundles through LCM.
The correct dimensions for a PE + PC + upgrade scenario are:
| Disk | Role | Size |
|---|---|---|
| Boot | Hypervisor (AHV) | 64 GB |
| CVM | Controller VM | 300 GB |
| Data | Primary storage tier | 500 GB minimum, 600 GB ideal |
This yields a usable storage pool of approximately 465 GB. Prism Central’s 500 GB disk is thin-provisioned, meaning it consumes actual space only as data is written. At initial deployment, PC uses roughly 50 GB. A 465 GB pool accommodates this comfortably, but a 125 GB pool does not.
Why this is irreversible: on a nested CE deployment, you cannot add a disk after installation. The Hades service, which manages disk discovery, does not assign a slot to a disk that was not present during the Phoenix imaging phase. The disk_add command fails silently or returns an error. The only option is to destroy the VM, recreate it with larger disks, and run Phoenix again.
Decision Two: Disk Roles and Identifiers
During the Phoenix imaging screen, each disk must be assigned a role: H for hypervisor boot, C for Controller VM, and D for data. These roles determine which partitions Phoenix writes to each disk. They cannot be reassigned after imaging.
Three rules apply:
- Three separate disks minimum. CE refuses to boot if the same disk is assigned multiple roles. This is different from some Nutanix configurations where boot and CVM can share a device.
- Each disk must have a unique serial number. When creating the VM with
virt-install, set theserial=parameter to a distinct value for each disk. Without unique serials, the cluster exhibits unpredictable behavior: disks appear to swap roles, or the CVM fails to mount the correct partition. - Use the SATA bus. Phoenix expects SATA devices. VirtIO disks are not recognized by the installer. This is a constraint of the CE imaging process, not of KVM itself.
A minimal virt-install invocation includes three --disk lines, each with bus=sata and a distinct serial= value. The exact syntax depends on your libvirt version, but the principle is the same: three disks, three roles, three serials, all SATA.
Decision Three: The IP Plan
A complete Nutanix CE deployment with Prism Central requires five IP addresses on the management network, all in the same subnet. These must be reserved before the first boot:
| Role | When assigned | Required for |
|---|---|---|
| AHV host | Phoenix imaging | Hypervisor management |
| CVM / Prism Element | Phoenix imaging | Cluster services, UI on port 9440 |
| Cluster Virtual IP | Post-install configuration | Stable cluster endpoint |
| iSCSI Data Services IP | Post-install configuration | Required for CMSP and Prism Central |
| Prism Central VM | PC deployment wizard | API endpoint, UI on port 9440 |
The first two are set during Phoenix imaging. The third and fourth are configured in Prism Element after the cluster is created. The fifth is assigned during the Prism Central deployment wizard.
Two traps in this plan:
The subnet mask must match your actual network. Phoenix defaults to 255.255.255.0 as a placeholder. If your management network is a /16, that placeholder will isolate the CVM from any host outside the /24. The CVM boots, the cluster creates, Prism Element loads, and everything appears to work — until you try to reach the VIP or deploy PC from a machine on a different /24 within the same /16. The fix is to enter the correct mask during imaging, but if you miss it, changing the CVM network configuration after installation is a manual process that requires SSH access to the AHV host and careful editing of the CVM configuration.
The VIP and DSIP must be set before deploying Prism Central. The PC deployment wizard checks for both. If either is missing, the wizard refuses to proceed. Setting them afterward is straightforward in Prism Element, but if you have already started the PC deployment and it failed because of the missing addresses, you must clean up the failed deployment before retrying.
Decision Four: The Upgrade Sequence
The CE installer ships AOS 6.8.1. If you need features from AOS 7.0 — such as the v4 API for VM management — you must upgrade through LCM (Life Cycle Management) in Prism Element.
Nutanix enforces an interoperability rule: Prism Central must be at a version compatible with the AOS it manages. This rule creates two opposite upgrade sequences depending on whether a PC is already registered:
| Scenario | Correct order | Reason |
|---|---|---|
| Fresh install, no PC yet | Upgrade AOS first, then deploy PC | No PC to desynchronize. Upgrading AOS makes the recent PC branches available. Deploy a PC that is natively compatible. |
| Existing cluster with PC registered | Upgrade PC first, then AOS | If AOS goes ahead of what the PC supports, the registration breaks. |
The LCM upgrade wizard always displays a warning: if this cluster is registered with Prism Central, ensure that Prism Central has been upgraded first. On a fresh install with no PC, this warning does not apply. You can verify with ncli multicluster get-cluster-state: if the registered cluster count is zero, you are in the first scenario.
A second trap in the upgrade: LCM may propose an AOS 6.10 LTS release by default. That is not the same as 7.0. You must explicitly select the 7.0.1.x branch in the version picker. Selecting 6.10 gives you a stable platform but without the features that require the 7.x branch.
Why this is irreversible: an AOS downgrade is not supported. If you upgrade to the wrong version, the only path is forward. And if you deploy a PC before upgrading AOS, and then upgrade AOS beyond what the PC supports, the PE-to-PC registration breaks. Recovering requires upgrading the PC separately, which on a small pool may not have enough space for the PC upgrade bundle.
Decision Five: Prism Central Size
In earlier Prism Central releases, an X-Small deployment option existed: 4 vCPU, 16 GB RAM, and a smaller disk footprint. On pc.7.5, X-Small no longer exists. The smallest available size is Small: 6 vCPU, 28 GB RAM, 500 GB disk.
The RAM implication is significant. The AHV host needs memory for itself, the CVM needs approximately 20 GB, and now PC Small needs 28 GB. The total approaches 52 GB before any workload VMs. A KVM host with 32 GB of RAM cannot run this stack. 64 GB is the practical minimum for a nested CE deployment with Prism Central.
The disk implication circles back to Decision One. The 500 GB disk is thin-provisioned: Prism Central does not allocate 500 GB of pool space on day one. But the storage pool must be large enough that thin provisioning does not hit a ceiling as PC grows over time. A 465 GB pool (from our recommended disk sizes) accommodates this. A 125 GB pool does not.
Why this is irreversible: Prism Central cannot be resized in place on CE. If you deploy a Small PC and later realize you need more resources, the only option is to destroy the PC, redeploy, and re-register. The PE data is not lost, but the PC configuration, any categories, and any policies defined in PC must be recreated.
Planning and validating these infrastructure decisions before committing to a deployment is the kind of work that our infrastructure design and deployment practice handles routinely, whether the target is Nutanix, Proxmox, or OpenStack. When the question is which platform fits your constraints, our architecture audit starts from the workload, not from the vendor.
Three Failures That Do Not Produce an Error
Beyond the five decisions, three failure modes deserve mention because they do not raise an error message. They appear to succeed and fail later.
The ISO not ejected before reboot. At the end of Phoenix imaging, the installer asks you to press Y to reboot. If the installation ISO is still attached, the VM boots back into the installer instead of into AHV. It looks like the installation is starting over. On a KVM host, eject the ISO with virsh change-media before confirming the reboot.
The cluster not created manually. CE 2.1 does not create the cluster automatically after the first boot. The CVM starts, the services initialize, but there is no cluster. Prism Element is not reachable on port 9440. The fix is to run cluster create from the CVM with the external CVM IP and the redundancy factor set to 1 for a single-node deployment. This step is easy to miss because the AHV login prompt appears normal.
The AHV version upgraded beyond 10.3. LCM may offer an AHV upgrade to 10.3 or later. Community reports confirm that AHV versions 10.3 and above break on CE. The upgrade completes without error, but the node becomes unstable afterward. The safe practice is to upgrade AOS only and leave AHV at its installed version.
What This Article Does Not Cover
This article covers the five decisions that must be made before and during a nested CE deployment, and the three silent failures to watch for. It does not provide a step-by-step installation procedure — the Nutanix Community Edition Getting Started Guide covers that. It does not cover multi-node clusters, replication factor 2 or 3, or production sizing. It does not cover the Nutanix API (v3 or v4) beyond noting that v4 requires AOS 7.0 and pc.7.5. And it does not cover deployment on physical hardware, where some of these constraints (particularly disk expansion and Hades slot assignment) behave differently.
The CE version documented here is 2.1, the latest available installer as of August 2026. There is no newer ISO. AOS 7.0 is obtained by LCM upgrade, not by a new installer.
References
Nutanix. Community Edition Getting Started Guide v2.1. portal.nutanix.com, 2025.
Nutanix. AOS and Prism Central Interoperability Matrix. portal.nutanix.com, 2026.
Nutanix Community Forum. Do not upgrade CE to AHV 10.3 and higher. next.nutanix.com, discussion #45028, 2025.
EC INTELLIGENCE. Formation Administration Nutanix — Runbook de déploiement Nutanix CE (nested). 2026.
