NCSE-Core cheat sheet

Nutanix Enterprise Cloud runs the same AOS software stack on appliance hardware, on validated third-party servers, or in public clouds (NC2 on AWS/Azure), so operational model is consistent across deployment targets.

Cluster minimum for production is typically 3 nodes; single-node and two-node clusters exist for ROBO/edge with two-node using a witness or back-to-back direct link for quorum.

AOS is the distributed platform layer (storage, VM management, cluster services); AHV is the native KVM-based hypervisor; Prism Element is per-cluster management, Prism Central is multi-cluster management.

Each node runs a Controller VM (CVM) that owns local disks and serves I/O to all nodes over the internal network; AHV hosts run the user VMs and the CVM is a VM on the same host.

Nutanix Cloud Platform layers: AOS/AHV (core HCI), Prism (management plane), Nutanix Cloud Manager (NCM) for cost/ops/self-service, Flow for networking/security, Files/Objects for unstructured data, Era for database lifecycle.

Cluster services that must be healthy include Cassandra (cluster metadata/config), Zookeeper (leader election/locking), Stargate (data I/O), and Prism; CVM memory is sized by cluster scale (small/large CVM sizing).

Genesis is the bootstrap/imaging service used to create or expand a cluster; Foundation images nodes and performs initial configuration before AOS cluster creation.

Licensing models include perpetual with support and term-based subscription (NCI Ultimate/Pro etc.); many advanced features (Flow, Files, DR runbooks) are license-gated, so confirm entitlement during design.

DSF aggregates local disks from all nodes into a single distributed pool; storage containers present datastores (NFS/SMB/iSCSI) to VMs and apply policies such as RF, compression, dedupe, and encryption at the container level.

Replication Factor (RF) is per container: RF2 tolerates one simultaneous disk/node failure for that data; RF3 tolerates two. Capacity usable is roughly raw capacity divided by RF, minus reserved/metadata overhead.

Data is written as extents in a vDisk; Stargate (the DSF I/O layer) writes locally and replicates to remote CVMs before acknowledging writes, so a node loss does not lose acknowledged data.

Curator is the background scanner that detects disk failures, rebuilds missing replicas, and performs disk balancing and garbage collection; rebuild time depends on capacity and network/disk throughput.

Nutanix uses a log-structured, copy-on-write extent store with checksums; ILM (intelligent lifecycle management) tiers cold data to higher-capacity nodes in mixed-node clusters.

Erasure Coding (EC-X, e.g., 4+1 or 6+2) reduces capacity overhead versus RF but is typically applied to cold/inactive data because it increases write amplification and rebuild cost.

Capacity planning: usable ≈ (raw − reserved) / RF, then subtract snapshot/container overhead; check 'capacity runway' in Prism and account for rebuild headroom of at least one node's worth of data.

Data locality matters: AHV VMs read from the local CVM when the extent is local; after a failure, non-local reads increase east-west traffic until Curator restores locality.

AHV is KVM-based and managed through Prism; VMs are defined by vCPU, memory, disks (vDisks on containers), NICs on virtual networks, and boot order/categories.

VM creation paths: Prism UI, REST API v3 (POST /vms), Acropolis CLI (acli), or image-based deployment from the image library (qcow2/raw/ova); sysprep/cloud-init enable guest customization.

Lifecycle operations: create, clone, snapshot, restore, migrate (live), power on/off, update (hot-add vCPU/memory/disks where guest OS supports), delete; VM categories drive policy, protection, and playbooks.

Live migration moves a running VM between hosts with minimal downtime; it requires shared storage (DSF is shared) and network reachability; affinity policies can block migration.

Affinity policies: VM-host affinity (pin VMs to hosts), VM-VM anti-affinity (spread critical VMs), and VM-VM affinity; policies are enforced during HA and migration.

AHV high availability restarts VMs on surviving hosts after a host failure; it is not guest-level clustering and does not preserve in-memory state.

Guest tools (Nutanix Guest Tools, NGT) enable VSS-consistent snapshots, self-service restore, and file-level restore for Windows; install NGT for application-consistent protection.

GPU and PCI passthrough, CPU pinning, and memory overcommit settings are per-VM; overcommit ratios affect consolidation design and HA admission control.

Each AHV host has an internal bridge (br0) and a default virtual switch (vs0); the CVM and host use bonded uplinks (balance-slb default, or LACP active-active/active-passive) to the physical network.

VLANs are configured as VLAN-backed networks on the virtual switch; VMs attach to VLANs; trunk uplinks carry multiple VLANs; native VLAN handling depends on upstream switch config.

CVM and AHV host management traffic should be on a dedicated VLAN with jumbo frames (MTU 9000) for best storage performance; user VM traffic is separated on its own VLANs.

Bond modes: balance-slb (no switch config, per-flow hashing, works with any switch), active-backup (failover only), LACP (requires switch LAG, higher throughput, active-active).

Network segmentation for design: management (Prism/CVM), storage/internal (CVM-to-CVM, ideally jumbo), VM data, backup/replication, and out-of-band IPMI; separate where policy or throughput requires.

IP address planning: each CVM needs a management IP; each host needs an AHV host IP; virtual IPs exist for Prism Element and Prism Central; reserve ranges and document them in the design.

Name resolution and NTP are prerequisites: CVMs and Prism Central must resolve each other and stay time-synced, or cluster services and certificate operations fail.

Physical switch requirements: redundant ToR pairs, MLAG/vPC for LACP, spanning-tree considerations, and MTU consistency end-to-end when jumbo frames are used.

Flow provides network security (distributed firewall), microsegmentation, and virtual networking (VPCs/overlay) managed from Prism Central; it requires Prism Central and is license-gated.

Flow Network Security applies policy at the vNIC level on AHV hosts, so traffic is filtered before it leaves the host; policies can be applied to VMs, categories, or VPCs.

Policy models: allow-list (default deny) or deny-list (default allow); best practice for microsegmentation is monitor mode first, then enforce with allow-lists scoped by application tiers.

Categories are the primary scoping mechanism (e.g., AppType:Web, Env:Prod); policy applied to categories scales without editing rules per VM.

Flow Virtual Networking (VPC) provides isolated virtual networks with their own IP space, routing, NAT, and optional connectivity to external networks; overlays use VXLAN/Geneve encapsulation.

Security policy types include isolation policies (deny between categories), application policies (allow specific flows), and quarantine; policy hit counters and flow visualization aid troubleshooting.

Flow does not replace perimeter firewalls; it complements them for east-west traffic. North-south traffic still traverses physical firewalls/load balancers unless designed otherwise.

Prerequisites: AHV only (Flow network security is AHV-specific), Prism Central registered to clusters, NGT optional but useful for guest-based visibility, and consistent category taxonomy across clusters.

Prism Element is the per-cluster UI/API for hardware, storage, VMs, alerts, and local tasks; Prism Central is a multi-cluster VM appliance that aggregates clusters and hosts NCM, Flow, Files, and DR features.

Prism Central sizing is by VM count and feature use (small/medium/large); it should be deployed as a 3-VM scale-out cluster for production resilience, not a single VM.

Key Prism Central capabilities: categories, RBAC with AD/LDAP, projects/self-service, reports, playbooks (automation), alerts/health, and license management.

Prism monitoring: alerts have severity and impact; health checks flag configuration drift (e.g., NTP, CVM memory, disk status); use 'Analysis' for capacity and performance trends.

REST API v3 is the primary automation interface (Prism Central) with v2 available on Prism Element; API keys or basic auth are used; v3 endpoints are intent-based (/vms, /clusters, /images).

nCLI is the Nutanix CLI on the CVM for advanced troubleshooting (e.g., cluster status, disk checks); acli manages VMs and hosts; use them when UI/API is unavailable.

Log collection (Prism > Support) and NCC (Nutanix Cluster Check) health checks are first-line diagnostics; NCC output guides support cases and upgrade readiness.

Upgrades: AOS, AHV, Prism Central, and firmware are upgraded separately; use LCM (Life Cycle Manager) for firmware and inventory, and follow upgrade paths/ compatibility matrices.

Protection domains group VMs by category or explicit list and define snapshot schedules (frequency, retention), replication targets, and consistency (crash-consistent vs NGT/VSS app-consistent).

Local snapshots are redirect-on-write and space-efficient; they are not backups - a cluster loss loses snapshots. Use replication or third-party backup for true DR.

Async replication sends changed extents to a remote cluster on a schedule; RPO equals the replication interval plus transfer time; sync replication is available for metro distances with strict latency limits.

RTO is driven by recovery method: snapshot restore (minutes, same cluster), replication failover (minutes to hours), or backup restore (hours). Document RTO/RPO per application tier.

Nutanix DR (formerly Leap) uses protection policies plus recovery plans (runbooks) with ordered VM boot groups, IP/GUEST customization, and one-click or planned failover/test failover.

Test failover validates runbooks without impacting production; planned failover is for maintenance/migration; unplanned failover is for disaster. Always test and document the reverse (failback) path.

Metro availability (stretched cluster with witness) provides near-zero RPO across two sites; it requires low-latency links (typically <5 ms RTT) and a third-site witness for quorum.

Backup integration: Nutanix supports VSS-based snapshots and partners (e.g., Veeam, HYCU) for long-term retention and offsite copies; snapshots alone do not satisfy retention/compliance requirements.

Nutanix Move migrates VMs from VMware ESXi, Hyper-V, AWS, or Azure to AHV; it does pre-checks, data seeding, and cutover with minimal downtime; source and target must be reachable.

Move requires credentials for the source hypervisor/cloud, network mapping (source network to AHV VLAN), and sufficient target capacity; test cutover in a lab or use dry-run where available.

Nutanix Cloud Clusters (NC2) runs AOS/AHV in AWS or Azure with the same Prism management; use it for cloud bursting, DR, and lift-and-shift; networking is via VPC/VNet and a VPN/ExpressRoute/Direct Connect to on-prem.

Hybrid cloud design: keep identity (AD), DNS, NTP, and IP addressing consistent; plan for latency-sensitive workloads to stay on-prem; use replication or backup for cross-site data movement.

Workload mobility options: live migration within a cluster, replication + DR failover across clusters, Move for hypervisor conversion, and NC2 for cloud placement.

Migration sizing: calculate target vCPU/memory/storage with overhead, account for container RF, and verify AHV guest OS support (virtio drivers) before cutover.

Cutover planning: freeze source, final delta sync, power on target, validate app, then decommission source after a rollback window; document rollback steps.

Network cutover is often the biggest risk: IP changes, DNS updates, firewall rules, and load balancer reconfiguration must be sequenced with VM cutover.

Discovery inputs: VM inventory (vCPU, memory, storage used/provisioned), performance baselines (IOPS, throughput, latency), growth rate, RTO/RPO, compliance, and network topology.

Sizing formula: usable capacity = raw capacity / RF; then apply reserve (typically 20-30% free), snapshot overhead, and rebuild headroom (one node's data) before comparing to demand.

Compute sizing: total vCPU demand / target vCPU-per-core ratio (often 4:1 to 6:1 depending on workload) = cores needed; memory is usually the binding constraint; leave N+1 host headroom for HA.

Performance sizing: compare workload IOPS/latency to node model capabilities; mixed-node clusters complicate ILM; all-flash for latency-sensitive, hybrid for capacity-oriented.

Node count drives resilience: 3 nodes minimum for RF2 production; 4+ nodes for RF3 or N+1; two-node + witness for ROBO; consider CVM memory sizing at scale.

Design deliverables: bill of materials, rack/power/cooling, network diagrams with VLANs and IP plan, RF/container design, protection policy (RPO/RTO), and migration plan.

Pre-sales qualification: confirm budget, timeline, decision criteria, competitive alternatives, and success metrics; map features to business outcomes (e.g., RTO reduction, rack consolidation).

Validate against the Nutanix Sizer and compatibility matrices; document assumptions and exclusions (e.g., third-party backup, WAN links) so the proposal is defensible.