NSEA cheat sheet

HCI consolidates compute, storage, and virtualization into the same x86 nodes; a distributed storage fabric (DSF) runs as a controller VM (CVM) on every node instead of a dedicated SAN array.

Nutanix AOS is the distributed platform software; AHV is the native KVM-based hypervisor; Prism is the management plane (Prism Element per cluster, Prism Central for multi-cluster).

Cluster types: a standard cluster runs AOS on Nutanix-certified hardware; Nutanix Cloud Clusters (NC2) extends the same AOS stack to public cloud bare metal.

Three-tier vs HCI decision rule: choose HCI when predictable scale-out, single-vendor support, and reduced SAN dependency matter; choose three-tier when existing array investment or specialized SAN features are mandatory.

A Nutanix cluster requires a minimum of 3 nodes for redundancy (RF2); RF3 requires at least 5 nodes so three replicas plus failure tolerance fit across distinct nodes.

Data locality is a design goal, not a guarantee: the CVM prefers to read and write locally, but rebalancing and failure events can move data.

Licensing tiers (Starter, Pro, Ultimate) gate features such as replication, deduplication, and security capabilities; sizing must confirm licensed features match the design.

Nutanix Bible terminology: extent = 1 MB unit of data; extent group = 4 MB container of extents; vDisk = block device presented to a VM.

Scale-out is non-disruptive: adding a node triggers automatic data redistribution, and the cluster remains online throughout.

Every node runs a CVM plus the AHV hypervisor; the CVM owns local disks and serves I/O to guest VMs over an internal network.

Cassandra (distributed metadata store) tracks where data lives; Stargate mediates I/O; Curator runs MapReduce-style background jobs such as disk balancing and scan.

Genesis is the cluster-formation and configuration service; it elects the cluster leader and manages node join/remove operations.

AOS distributes metadata as a replicated, eventually consistent key-value store; losing a CVM triggers metadata re-replication and I/O redirection to surviving replicas.

Prism Central is a separate VM (or set of VMs) that aggregates Prism Element data; it enables categories, policies, and multi-cluster operations.

Failure domains include node, block, disk, and rack; rack awareness must be configured so replicas land on distinct racks when racks exist.

Cluster health depends on quorum: metadata replication requires a majority of Cassandra nodes, so simultaneous CVM loss can make the cluster read-only or unavailable.

Upgrades are rolling: AOS and hypervisor upgrades proceed node by node, with VMs live-migrated off the node being upgraded.

Replication Factor (RF) is the number of copies of each extent: RF2 tolerates one node/disk failure; RF3 tolerates two, at the cost of ~50% usable capacity versus RF2.

Effective capacity ≈ raw usable capacity ÷ RF, minus reserved space; always subtract CVM overhead and the default reserve before quoting usable capacity.

Erasure coding (EC-X) reduces capacity overhead versus RF for cold data; it is not a substitute for RF on hot or latency-sensitive workloads.

Snapshots are metadata-based and near-instant; they consume capacity only as changed blocks diverge from the snapshot point.

Protection Domains group VMs for consistent snapshot and replication; a consistency group ensures multi-VM crash consistency.

Async replication (Nutanix Leap / DR) sends changed extents to a remote cluster on a schedule; RPO equals the replication interval plus lag, RTO depends on recovery workflow.

Metro Availability (synchronous replication) requires low-latency links (typically ≤5 ms RTT) and provides near-zero RPO with automatic failover between sites.

Deduplication (capacity or inline) and compression reduce footprint; dedup gains depend on data similarity and are weakest on encrypted or pre-compressed data.

Self-healing: on disk or node failure, Curator re-replicates affected extents to restore the configured RF; monitor rebuild progress and free capacity during recovery.

AHV uses Open vSwitch (OVS) for virtual switching; each host has a bridge (br0) that carries management, storage, and guest traffic unless separated.

Best practice: separate VLANs for management (CVM/host), storage (CVM-to-CVM replication and I/O), and guest VM traffic to isolate latency-sensitive storage flows.

The backplane network carries CVM-to-CVM traffic; 10 GbE or higher per node is standard, and 25 GbE is common for storage-heavy designs.

AHV supports VLAN-backed networks and IP address management (IPAM) for guest VM address assignment; overlay networks can extend L2 across sites.

Live migration (AHV) moves a running VM between hosts; it requires shared network reachability and sufficient bandwidth to complete within the migration window.

Nutanix Flow provides distributed firewall and microsegmentation at the vNIC level; policies follow the VM, not the physical port.

Bond modes: active-backup provides redundancy without aggregation; LACP (802.3ad) requires switch-side configuration and aggregates throughput.

Jumbo frames (MTU 9000) must be configured end-to-end on the storage network; a mismatch causes fragmentation and performance degradation.

Pre-install checklist: Nutanix-certified hardware, current AOS/hypervisor compatibility matrix, IP addressing plan, DNS/NTP, and out-of-band management access.

Foundation (or the newer installer workflow) images nodes and forms the cluster; it requires a configuration file describing node IPs, CVM IPs, and cluster VIP.

The cluster virtual IP (VIP) fronts Prism Element; the Prism Central VIP is separate and must be planned in DNS.

Node expansion: rack the node, cable it, run the cluster expansion workflow from Prism, and confirm the new CVM joins quorum before rebalancing data.

Expansion requires matching AOS versions across nodes; upgrade the existing cluster to the target version before adding a node with newer software.

Capacity planning rule: expansion should be triggered before free space falls below the reserve needed for rebuilds (typically keep ≥ 20–30% headroom).

Cluster removal/decommission: place the node in maintenance mode, evacuate data, then remove it from the cluster; never power off a CVM without evacuation unless the cluster can tolerate it.

Post-deployment validation includes NCC health checks, cluster status, and verifying replication and backup policies are applied.

Prism Element manages a single cluster; Prism Central aggregates clusters and provides categories, policies, and reporting across the estate.

NCC (Nutanix Cluster Check) runs health checks; schedule regular NCC runs and review failures before they escalate.

Alerts flow through Prism and can forward to SNMP, syslog, or email; alert policies should be tuned to avoid noise while preserving critical signals.

Categories are key-value tags applied to VMs; policies (protection, security, placement) are applied by category rather than by individual VM.

Lifecycle Manager (LCM) manages AOS, hypervisor, firmware, and NCC updates; inventory compliance before scheduling upgrades.

One-click upgrade and rolling upgrades minimize downtime, but always verify snapshots/backups and compatibility before starting.

Metrics to monitor: cluster IOPS/latency, CVM CPU/memory, storage capacity and rebuild status, and replication lag for DR.

Runbooks should cover node failure, CVM failure, capacity exhaustion, and DR failover; test DR failover periodically to validate RTO.

Discovery inputs: workload mix, VM count and vCPU/vRAM per VM, IOPS and latency targets, capacity growth rate, RPO/RTO, compliance, and network topology.

Sizing formula (capacity): usable capacity needed = (current data + growth) × RF ÷ (1 − reserve %); confirm against the vendor sizing tool, never quote raw capacity.

Sizing formula (compute): required cores = Σ(vCPU per VM × VM count) ÷ target vCPU-per-core consolidation ratio; add N+1 headroom for failure tolerance.

IOPS sizing: aggregate workload IOPS must fit within cluster IOPS at the target latency; random read/write mix and block size change the achievable number.

RF choice drives cost: RF2 for standard resilience, RF3 for stricter durability or larger failure domains; EC-X for cold capacity-heavy data.

Design for N+1 (or N+2) node failure tolerance and confirm the cluster still meets performance targets with a node down.

Network design must account for storage replication traffic (RF × write bandwidth) and DR replication bandwidth on the WAN.

Pre-sales deliverables: bill of materials, sizing report, network diagram, DR design with RPO/RTO, and a support/licensing summary - all validated against current compatibility matrices.

HCI merges compute and storage into the same node; the distributed storage fabric runs as a controller VM on every host, replacing a dedicated SAN.

AOS is the platform software, AHV is the native KVM hypervisor, and Prism is the management plane with Prism Element per cluster and Prism Central across clusters.

A minimum of three nodes is required for RF2 redundancy; RF3 needs at least five nodes to place three replicas with failure tolerance.

Data locality is a preference, not a guarantee: the CVM prefers local reads and writes, but rebalancing and failures can move data.

Licensing tiers gate features such as replication, deduplication, and security; sizing must confirm the licensed feature set matches the design.

Core terminology: an extent is 1 MB of data, an extent group holds 4 MB of extents, and a vDisk is the block device presented to a guest VM.

Scale-out is non-disruptive: adding a node triggers automatic data redistribution while the cluster stays online.

Each node runs a CVM and the AHV hypervisor; the CVM owns local disks and serves I/O to guest VMs over an internal network.

Cassandra stores distributed metadata about data location, Stargate mediates I/O, and Curator runs background jobs such as disk balancing and scans.

Genesis handles cluster formation and configuration, elects the cluster leader, and manages node join and removal operations.

Metadata is replicated and eventually consistent; losing a CVM triggers metadata re-replication and I/O redirection to surviving replicas.

Prism Central is a separate VM or VM set that aggregates Prism Element data and enables categories, policies, and multi-cluster operations.

Failure domains include node, block, disk, and rack; rack awareness must be configured so replicas land on distinct racks.

Quorum matters: metadata replication needs a majority of Cassandra nodes, so simultaneous CVM loss can make the cluster read-only or unavailable.

Upgrades are rolling: AOS and hypervisor upgrades proceed node by node, with VMs live-migrated off the node being upgraded.

Replication Factor is the number of copies of each extent: RF2 tolerates one failure, RF3 tolerates two, at roughly 50% usable capacity versus RF2.

Effective capacity is approximately raw usable capacity divided by RF, minus reserved space and CVM overhead; never quote raw capacity as usable.

Erasure coding (EC-X) reduces capacity overhead versus RF for cold data but is not a substitute for RF on hot or latency-sensitive workloads.

Snapshots are metadata-based and near-instant; they consume capacity only as changed blocks diverge from the snapshot point.

Protection Domains group VMs for consistent snapshot and replication; a consistency group ensures multi-VM crash consistency.

Async replication sends changed extents on a schedule; RPO equals the replication interval plus lag, while RTO depends on the recovery workflow.

Metro Availability uses synchronous replication, requires low-latency links (typically ≤5 ms RTT), and provides near-zero RPO with automatic failover.

Deduplication and compression reduce footprint, but gains depend on data similarity and are weakest on encrypted or pre-compressed data.

Self-healing: on disk or node failure, Curator re-replicates affected extents to restore the configured RF; monitor rebuild progress and free capacity.

AHV uses Open vSwitch for virtual switching; each host has a bridge (br0) carrying management, storage, and guest traffic unless separated.

Separate VLANs for management, storage, and guest traffic isolate latency-sensitive storage flows from general VM traffic.

The backplane network carries CVM-to-CVM traffic; 10 GbE or higher per node is standard, with 25 GbE common for storage-heavy designs.

AHV supports VLAN-backed networks and IP address management for guest VMs; overlay networks can extend Layer 2 across sites.

Live migration moves a running VM between hosts and requires shared network reachability plus sufficient bandwidth to finish within the migration window.

Nutanix Flow provides distributed firewall and microsegmentation at the vNIC level, so policies follow the VM rather than the physical port.

Bond modes: active-backup provides redundancy without aggregation; LACP (802.3ad) requires switch-side configuration and aggregates throughput.

Jumbo frames (MTU 9000) must be configured end-to-end on the storage network; a mismatch causes fragmentation and performance degradation.

Pre-install checklist: certified hardware, current compatibility matrix, IP addressing plan, DNS and NTP, and out-of-band management access.

Foundation images nodes and forms the cluster from a configuration file describing node IPs, CVM IPs, and the cluster VIP.

The cluster virtual IP fronts Prism Element; the Prism Central VIP is separate and must be planned in DNS.

Node expansion: rack and cable the node, run the cluster expansion workflow from Prism, and confirm the new CVM joins quorum before rebalancing.

Expansion requires matching AOS versions; upgrade the existing cluster to the target version before adding a node with newer software.

Trigger expansion before free space falls below the rebuild reserve; keep roughly 20–30% headroom for recovery operations.

Decommissioning: place the node in maintenance mode, evacuate data, then remove it from the cluster; never power off a CVM without evacuation unless the cluster can tolerate it.

Post-deployment validation includes NCC health checks, cluster status, and confirmation that replication and backup policies are applied.

Prism Element manages a single cluster; Prism Central aggregates clusters and provides categories, policies, and cross-estate reporting.

NCC runs health checks; schedule regular runs and review failures before they escalate into outages.

Alerts flow through Prism and can forward to SNMP, syslog, or email; tune alert policies to cut noise while preserving critical signals.

Categories are key-value tags applied to VMs; protection, security, and placement policies are applied by category rather than per VM.

Lifecycle Manager manages AOS, hypervisor, firmware, and NCC updates; inventory compliance before scheduling upgrades.

Rolling upgrades minimize downtime, but always verify snapshots, backups, and compatibility before starting.

Monitor cluster IOPS and latency, CVM CPU and memory, storage capacity and rebuild status, and replication lag for DR.

Runbooks should cover node failure, CVM failure, capacity exhaustion, and DR failover; test DR failover periodically to validate RTO.

Discovery inputs: workload mix, VM count and vCPU/vRAM per VM, IOPS and latency targets, growth rate, RPO/RTO, compliance, and network topology.

Capacity formula: usable capacity needed = (current data + growth) × RF ÷ (1 − reserve %); confirm with the vendor sizing tool, never quote raw capacity.

Compute formula: required cores = Σ(vCPU per VM × VM count) ÷ target vCPU-per-core ratio, plus N+1 headroom for failure tolerance.

IOPS sizing: aggregate workload IOPS must fit within cluster IOPS at the target latency; read/write mix and block size change the achievable number.

RF choice drives cost: RF2 for standard resilience, RF3 for stricter durability or larger failure domains, and EC-X for cold capacity-heavy data.

Design for N+1 or N+2 node failure tolerance and confirm the cluster still meets performance targets with a node down.

Network design must account for storage replication traffic (RF × write bandwidth) and DR replication bandwidth on the WAN.

Pre-sales deliverables: bill of materials, sizing report, network diagram, DR design with RPO/RTO, and a support and licensing summary validated against current matrices.

HCI consolidates compute and storage on the same x86 nodes; the distributed storage fabric runs as a controller VM on every host instead of a dedicated SAN array.

AOS is the distributed platform software; AHV is the native KVM-based hypervisor; Prism is the management plane with Prism Element per cluster and Prism Central across clusters.

Cluster types: standard clusters run AOS on Nutanix-certified hardware, while Nutanix Cloud Clusters extends the same AOS stack to public cloud bare metal.

HCI versus three-tier decision rule: choose HCI for predictable scale-out and single-vendor support; choose three-tier when existing array investment or specialized SAN features are mandatory.

A minimum of three nodes is required for RF2 redundancy; RF3 requires at least five nodes so three replicas plus failure tolerance fit across distinct nodes.

Data locality is a design goal, not a guarantee: the CVM prefers local reads and writes, but rebalancing and failure events can move data.

Licensing tiers such as Starter, Pro, and Ultimate gate features including replication, deduplication, and security; sizing must confirm licensed features match the design.

Core terminology: an extent is 1 MB of data, an extent group holds 4 MB of extents, and a vDisk is the block device presented to a guest VM.

Scale-out is non-disruptive: adding a node triggers automatic data redistribution while the cluster remains online throughout.

Every node runs a CVM plus the AHV hypervisor; the CVM owns local disks and serves I/O to guest VMs over an internal network.

Cassandra tracks where data lives, Stargate mediates I/O, and Curator runs MapReduce-style background jobs such as disk balancing and scans.

Genesis is the cluster-formation and configuration service; it elects the cluster leader and manages node join and remove operations.

Metadata is stored as a replicated, eventually consistent key-value store; losing a CVM triggers metadata re-replication and I/O redirection to surviving replicas.

Prism Central is a separate VM or set of VMs that aggregates Prism Element data and enables categories, policies, and multi-cluster operations.

Failure domains include node, block, disk, and rack; rack awareness must be configured so replicas land on distinct racks when racks exist.

Cluster health depends on quorum: metadata replication requires a majority of Cassandra nodes, so simultaneous CVM loss can make the cluster read-only or unavailable.

Upgrades are rolling: AOS and hypervisor upgrades proceed node by node, with VMs live-migrated off the node being upgraded.

Replication Factor is the number of copies of each extent: RF2 tolerates one node or disk failure, while RF3 tolerates two at roughly 50% usable capacity versus RF2.

Effective capacity is approximately raw usable capacity divided by RF, minus reserved space; always subtract CVM overhead and the default reserve before quoting usable capacity.

Erasure coding reduces capacity overhead versus RF for cold data; it is not a substitute for RF on hot or latency-sensitive workloads.

Snapshots are metadata-based and near-instant; they consume capacity only as changed blocks diverge from the snapshot point.

Protection Domains group VMs for consistent snapshot and replication; a consistency group ensures multi-VM crash consistency.

Async replication sends changed extents to a remote cluster on a schedule; RPO equals the replication interval plus lag, while RTO depends on the recovery workflow.

Metro Availability uses synchronous replication, requires low-latency links (typically ≤5 ms RTT), and provides near-zero RPO with automatic failover between sites.

Deduplication and compression reduce footprint; gains depend on data similarity and are weakest on encrypted or pre-compressed data.

Self-healing: on disk or node failure, Curator re-replicates affected extents to restore the configured RF; monitor rebuild progress and free capacity during recovery.

AHV uses Open vSwitch for virtual switching; each host has a bridge (br0) carrying management, storage, and guest traffic unless those are separated.

Best practice: separate VLANs for management (CVM and host), storage (CVM-to-CVM replication and I/O), and guest VM traffic to isolate latency-sensitive storage flows.

The backplane network carries CVM-to-CVM traffic; 10 GbE or higher per node is standard, and 25 GbE is common for storage-heavy designs.

AHV supports VLAN-backed networks and IP address management for guest VM address assignment; overlay networks can extend Layer 2 across sites.

Live migration moves a running VM between hosts; it requires shared network reachability and sufficient bandwidth to complete within the migration window.

Nutanix Flow provides distributed firewall and microsegmentation at the vNIC level, so policies follow the VM rather than the physical port.

Bond modes: active-backup provides redundancy without aggregation, while LACP (802.3ad) requires switch-side configuration and aggregates throughput.

Jumbo frames (MTU 9000) must be configured end-to-end on the storage network; a mismatch causes fragmentation and performance degradation.

Pre-install checklist: Nutanix-certified hardware, current AOS and hypervisor compatibility matrix, IP addressing plan, DNS and NTP, and out-of-band management access.

Foundation images nodes and forms the cluster; it requires a configuration file describing node IPs, CVM IPs, and the cluster VIP.

The cluster virtual IP fronts Prism Element; the Prism Central VIP is separate and must be planned in DNS.

Node expansion: rack the node, cable it, run the cluster expansion workflow from Prism, and confirm the new CVM joins quorum before rebalancing data.

Expansion requires matching AOS versions across nodes; upgrade the existing cluster to the target version before adding a node with newer software.

Capacity planning rule: trigger expansion before free space falls below the reserve needed for rebuilds, typically keeping at least 20–30% headroom.

Decommissioning: place the node in maintenance mode, evacuate data, then remove it from the cluster; never power off a CVM without evacuation unless the cluster can tolerate it.

Post-deployment validation includes NCC health checks, cluster status, and verifying that replication and backup policies are applied.

Prism Element manages a single cluster; Prism Central aggregates clusters and provides categories, policies, and reporting across the estate.

NCC runs health checks; schedule regular NCC runs and review failures before they escalate into outages.

Alerts flow through Prism and can forward to SNMP, syslog, or email; tune alert policies to reduce noise while preserving critical signals.

Categories are key-value tags applied to VMs; protection, security, and placement policies are applied by category rather than by individual VM.

Lifecycle Manager manages AOS, hypervisor, firmware, and NCC updates; inventory compliance before scheduling upgrades.

Rolling upgrades minimize downtime, but always verify snapshots, backups, and compatibility before starting.

Metrics to monitor: cluster IOPS and latency, CVM CPU and memory, storage capacity and rebuild status, and replication lag for DR.

Runbooks should cover node failure, CVM failure, capacity exhaustion, and DR failover; test DR failover periodically to validate RTO.

Discovery inputs: workload mix, VM count and vCPU/vRAM per VM, IOPS and latency targets, capacity growth rate, RPO/RTO, compliance, and network topology.

Capacity formula: usable capacity needed = (current data + growth) × RF ÷ (1 − reserve %); confirm against the vendor sizing tool and never quote raw capacity.

Compute formula: required cores = Σ(vCPU per VM × VM count) ÷ target vCPU-per-core consolidation ratio, plus N+1 headroom for failure tolerance.

IOPS sizing: aggregate workload IOPS must fit within cluster IOPS at the target latency; random read/write mix and block size change the achievable number.

RF choice drives cost: RF2 for standard resilience, RF3 for stricter durability or larger failure domains, and erasure coding for cold capacity-heavy data.

Design for N+1 or N+2 node failure tolerance and confirm the cluster still meets performance targets with a node down.

Network design must account for storage replication traffic (RF × write bandwidth) and DR replication bandwidth on the WAN.

Pre-sales deliverables: bill of materials, sizing report, network diagram, DR design with RPO/RTO, and a support and licensing summary validated against current compatibility matrices.

HCI consolidates compute, storage, and virtualization into the same x86 nodes; a distributed storage fabric runs as a controller VM on every node instead of a dedicated SAN array.

Nutanix AOS is the distributed platform software; AHV is the native KVM-based hypervisor; Prism is the management plane with Prism Element per cluster and Prism Central for multi-cluster.

Cluster types: a standard cluster runs AOS on Nutanix-certified hardware; Nutanix Cloud Clusters extends the same AOS stack to public cloud bare metal.

Three-tier versus HCI decision rule: choose HCI when predictable scale-out, single-vendor support, and reduced SAN dependency matter; choose three-tier when existing array investment or specialized SAN features are mandatory.

A Nutanix cluster requires a minimum of three nodes for redundancy (RF2); RF3 requires at least five nodes so three replicas plus failure tolerance fit across distinct nodes.

Data locality is a design goal, not a guarantee: the CVM prefers to read and write locally, but rebalancing and failure events can move data.

Licensing tiers such as Starter, Pro, and Ultimate gate features including replication, deduplication, and security capabilities; sizing must confirm licensed features match the design.

Nutanix terminology: an extent is a 1 MB unit of data, an extent group is a 4 MB container of extents, and a vDisk is the block device presented to a VM.

Scale-out is non-disruptive: adding a node triggers automatic data redistribution, and the cluster remains online throughout.

Every node runs a CVM plus the AHV hypervisor; the CVM owns local disks and serves I/O to guest VMs over an internal network.

Cassandra (distributed metadata store) tracks where data lives; Stargate mediates I/O; Curator runs MapReduce-style background jobs such as disk balancing and scan.

Genesis is the cluster-formation and configuration service; it elects the cluster leader and manages node join and remove operations.

AOS distributes metadata as a replicated, eventually consistent key-value store; losing a CVM triggers metadata re-replication and I/O redirection to surviving replicas.

Prism Central is a separate VM or set of VMs that aggregates Prism Element data; it enables categories, policies, and multi-cluster operations.

Failure domains include node, block, disk, and rack; rack awareness must be configured so replicas land on distinct racks when racks exist.

Cluster health depends on quorum: metadata replication requires a majority of Cassandra nodes, so simultaneous CVM loss can make the cluster read-only or unavailable.

Upgrades are rolling: AOS and hypervisor upgrades proceed node by node, with VMs live-migrated off the node being upgraded.

Replication Factor (RF) is the number of copies of each extent: RF2 tolerates one node or disk failure; RF3 tolerates two, at the cost of roughly 50% usable capacity versus RF2.

Effective capacity is approximately raw usable capacity divided by RF, minus reserved space; always subtract CVM overhead and the default reserve before quoting usable capacity.

Erasure coding (EC-X) reduces capacity overhead versus RF for cold data; it is not a substitute for RF on hot or latency-sensitive workloads.

Snapshots are metadata-based and near-instant; they consume capacity only as changed blocks diverge from the snapshot point.

Protection Domains group VMs for consistent snapshot and replication; a consistency group ensures multi-VM crash consistency.

Async replication sends changed extents to a remote cluster on a schedule; RPO equals the replication interval plus lag, while RTO depends on the recovery workflow.

Metro Availability (synchronous replication) requires low-latency links (typically ≤5 ms RTT) and provides near-zero RPO with automatic failover between sites.

Deduplication (capacity or inline) and compression reduce footprint; dedup gains depend on data similarity and are weakest on encrypted or pre-compressed data.

Self-healing: on disk or node failure, Curator re-replicates affected extents to restore the configured RF; monitor rebuild progress and free capacity during recovery.

AHV uses Open vSwitch (OVS) for virtual switching; each host has a bridge (br0) that carries management, storage, and guest traffic unless separated.

Best practice: separate VLANs for management (CVM and host), storage (CVM-to-CVM replication and I/O), and guest VM traffic to isolate latency-sensitive storage flows.

The backplane network carries CVM-to-CVM traffic; 10 GbE or higher per node is standard, and 25 GbE is common for storage-heavy designs.

AHV supports VLAN-backed networks and IP address management (IPAM) for guest VM address assignment; overlay networks can extend Layer 2 across sites.

Live migration moves a running VM between hosts; it requires shared network reachability and sufficient bandwidth to complete within the migration window.

Nutanix Flow provides distributed firewall and microsegmentation at the vNIC level; policies follow the VM, not the physical port.

Bond modes: active-backup provides redundancy without aggregation; LACP (802.3ad) requires switch-side configuration and aggregates throughput.

Jumbo frames (MTU 9000) must be configured end-to-end on the storage network; a mismatch causes fragmentation and performance degradation.

Pre-install checklist: Nutanix-certified hardware, current AOS and hypervisor compatibility matrix, IP addressing plan, DNS and NTP, and out-of-band management access.

Foundation images nodes and forms the cluster; it requires a configuration file describing node IPs, CVM IPs, and the cluster VIP.

The cluster virtual IP (VIP) fronts Prism Element; the Prism Central VIP is separate and must be planned in DNS.

Node expansion: rack the node, cable it, run the cluster expansion workflow from Prism, and confirm the new CVM joins quorum before rebalancing data.

Expansion requires matching AOS versions across nodes; upgrade the existing cluster to the target version before adding a node with newer software.

Capacity planning rule: trigger expansion before free space falls below the reserve needed for rebuilds, typically keeping at least 20–30% headroom.

Decommissioning: place the node in maintenance mode, evacuate data, then remove it from the cluster; never power off a CVM without evacuation unless the cluster can tolerate it.

Post-deployment validation includes NCC health checks, cluster status, and verifying that replication and backup policies are applied.

Prism Element manages a single cluster; Prism Central aggregates clusters and provides categories, policies, and reporting across the estate.

NCC (Nutanix Cluster Check) runs health checks; schedule regular NCC runs and review failures before they escalate into outages.

Alerts flow through Prism and can forward to SNMP, syslog, or email; tune alert policies to reduce noise while preserving critical signals.

Categories are key-value tags applied to VMs; protection, security, and placement policies are applied by category rather than by individual VM.

Lifecycle Manager (LCM) manages AOS, hypervisor, firmware, and NCC updates; inventory compliance before scheduling upgrades.

Rolling upgrades minimize downtime, but always verify snapshots, backups, and compatibility before starting.

Metrics to monitor: cluster IOPS and latency, CVM CPU and memory, storage capacity and rebuild status, and replication lag for DR.

Runbooks should cover node failure, CVM failure, capacity exhaustion, and DR failover; test DR failover periodically to validate RTO.

Discovery inputs: workload mix, VM count and vCPU/vRAM per VM, IOPS and latency targets, capacity growth rate, RPO/RTO, compliance, and network topology.

Capacity formula: usable capacity needed = (current data + growth) × RF ÷ (1 − reserve %); confirm against the vendor sizing tool and never quote raw capacity.

Compute formula: required cores = Σ(vCPU per VM × VM count) ÷ target vCPU-per-core consolidation ratio, plus N+1 headroom for failure tolerance.

IOPS sizing: aggregate workload IOPS must fit within cluster IOPS at the target latency; random read/write mix and block size change the achievable number.

RF choice drives cost: RF2 for standard resilience, RF3 for stricter durability or larger failure domains, and erasure coding for cold capacity-heavy data.

Design for N+1 or N+2 node failure tolerance and confirm the cluster still meets performance targets with a node down.

Network design must account for storage replication traffic (RF × write bandwidth) and DR replication bandwidth on the WAN.

Pre-sales deliverables: bill of materials, sizing report, network diagram, DR design with RPO/RTO, and a support and licensing summary validated against current compatibility matrices.