Nutanix NCP-CI-Azure cheat sheet

NC2 (Nutanix Cloud Clusters) runs the Nutanix AOS/AHV stack as a bare-metal Azure offering: each cluster node is a dedicated Azure BareMetal instance, not a nested VM on shared hypervisor hosts.

A Prism Central instance can manage both on-premises and NC2 clusters; a single Prism Central spanning sites enables cross-site networking and protection policies, but latency between Prism Central and managed clusters must stay within Nutanix-supported limits.

Cluster creation is driven from the NC2 console: you select Azure subscription, region, resource group, VPC/VNet, node count, and the AHV cluster profile; Azure quota for the chosen BareMetal SKU must be approved in the target region first.

NC2 node SKUs map to fixed CPU/memory/NVMe profiles; scaling adds whole nodes (no partial-node scaling), and scale-down requires the cluster to tolerate the resulting capacity loss.

AOS storage is local NVMe per node with replication factor typically 2 or 3; the effective usable capacity is roughly raw capacity divided by RF, minus reserved/metadata overhead.

Azure networking for NC2 uses a delegated subnet in a customer VNet; NC2 manages the cluster's internal network and exposes management/data traffic through that VNet's routing.

AHV VLANs are mapped to Azure VNet/subnet constructs; guest VM traffic egresses through the VNet and is subject to Azure NSGs, UDRs, and Azure firewall/NVA inspection.

Deployment requires registering the NC2 service in the Azure subscription and granting the NC2 service principal the RBAC roles it needs on the target subscription/resource group.

Cluster lifecycle operations (prism central registration, LCM updates, node replacement) are performed through NC2 console and Prism; Azure-side changes to the delegated subnet or VNet can break NC2 management plane connectivity.

NC2 clusters live in a customer VNet: hub-and-spoke with Azure Virtual WAN or VNet peering is the standard pattern for reaching on-premises via ExpressRoute or VPN Gateway.

Azure Bastion provides RDP/SSH to NC2 guest VMs without public IPs; avoid exposing Prism or guest management interfaces directly to the internet.

NSGs attach at subnet or NIC level; because AHV VLANs map to subnets, NSG rules are the primary L3/L4 filter for NC2 guest traffic.

User Defined Routes override Azure system routes; to force NC2 guest traffic through an NVA/firewall, add a UDR on the NC2 subnet pointing 0.0.0.0/0 (or specific prefixes) to the NVA private IP.

Azure Private DNS zones and custom DNS servers configured on the VNet are how NC2 guest VMs resolve Azure PaaS private endpoints and on-premises AD DNS names.

Microsoft Entra ID (Azure AD) integration for Prism uses SAML/OIDC identity provider configuration; directory-based role mapping assigns Prism roles to Entra groups rather than individual users.

For Windows guest domain join, deploy domain controllers reachable from the NC2 VNet (in Azure or via ExpressRoute) and point the VNet DNS at them; AHV guests use standard OS-level join.

Azure RBAC governs the NC2 service principal's ability to create/modify BareMetal hosts and networking; Prism RBAC governs who can operate the Nutanix cluster and VMs - the two planes are separate.

Prism Central provides a single pane across on-premises and NC2 clusters; categories and projects are used to organize VMs consistently across sites.

Nutanix Calm blueprints can deploy multi-tier applications to on-premises AHV and NC2 targets from the same Prism Central, enabling consistent app delivery.

Nutanix Clusters (NC2) console handles Azure-side infrastructure operations (node add/remove, cluster create/delete, networking changes); Prism handles VM-level operations.

LCM (Life Cycle Manager) in Prism manages AOS/AHV and firmware updates; NC2 imposes supported-version constraints, so verify the NC2-supported AOS release before upgrading.

Nutanix Flow network security policies are defined in Prism Central and apply to NC2 guest VMs, giving microsegmentation independent of Azure NSGs (defense in depth).

Monitoring: Prism health checks and alerts cover the Nutanix stack; Azure Monitor/Log Analytics covers the underlying BareMetal hosts and VNet. Correlate both for full-stack visibility.

Capacity planning on NC2 must account for Azure BareMetal SKU limits per region and subscription quota; scale-out is gated by Azure quota approval, not just Nutanix licensing.

Nutanix Move migrates VMs between on-premises AHV/ESXi/Hyper-V and NC2 AHV; it performs a pre-check, does an initial sync, then a cutover sync to minimize downtime.

Prism Central RBAC roles (e.g., Prism Admin, Prism Viewer, Project Admin) should be scoped per project to separate on-premises and Azure operations teams.

Nutanix Protection Domains (PDs) define the consistency group and replication schedule; Protection Policies in Prism Central apply PDs to VMs by category, enabling policy-driven DR.

Async replication is the standard for cross-site DR (on-prem to NC2 or NC2 to NC2); sync replication is only viable with very low-latency links.

Recovery Plans in Prism Central orchestrate failover: they define VM boot order, IP address changes, and scripts; test failover validates the plan without affecting production.

For NC2 DR, the target cluster must have sufficient capacity and matching network constructs (VNet/subnets, NSGs, DNS) pre-provisioned; failover does not create Azure networking.

Nutanix Mine / third-party backup integration can send backups to Azure Blob; Nutanix Files and Volumes have their own snapshot/replication semantics.

Nutanix Move supports agent-based and agentless migration; agentless uses VMware/Hyper-V APIs, agent-based installs into the guest OS for broader source support.

Migration cutover requires a final incremental sync, then power-off of the source and power-on of the target; DNS and IP changes must be planned because NC2 guests get IPs from the NC2/Azure network, not the on-prem network.

RPO is determined by replication frequency; RTO is determined by recovery plan automation plus VM boot time and any post-boot scripts.

Snapshot schedules and retention are configured in Protection Policies; local snapshots protect against logical corruption, remote replication protects against site loss.

Azure Policy can enforce allowed regions, required tags, and denied resource types on the subscription hosting NC2; use it to prevent drift from approved NC2 configurations.

Management groups provide hierarchical policy and RBAC inheritance above subscriptions; place NC2 subscriptions under a dedicated management group for consistent governance.

Microsoft Defender for Cloud provides posture management and threat detection for the Azure resources underlying NC2 (BareMetal hosts, VNet, storage); it does not inspect inside AHV guests.

For guest-level security, use Nutanix Flow for microsegmentation plus OS-level agents (EDR) inside guest VMs; Azure NSGs alone do not see intra-VLAN traffic on AHV.

Cost drivers for NC2: BareMetal instance hours (billed per node per hour, running whether or not VMs are powered on), Azure storage for backups, egress bandwidth, and ExpressRoute/VPN.

Reserved instances / savings plans may apply to eligible Azure components; BareMetal pricing and commitment options should be verified per region because availability varies.

Tag NC2 resource groups with cost center, environment, and owner; use Azure Cost Management budgets and alerts scoped to the NC2 resource group.

Egress from Azure to on-premises over ExpressRoute is metered; large migrations and replication traffic should be sized and budgeted accordingly.

Least privilege: scope the NC2 service principal to the minimum RBAC roles on the specific resource group rather than subscription Owner.

NC2 nodes are dedicated Azure BareMetal hosts; AOS runs directly on the hardware, so AHV is the hypervisor and there is no nested virtualization penalty.

Because nodes are dedicated, noisy-neighbor effects from other Azure tenants are eliminated, which matters for predictable storage and CPU latency.

Each NC2 cluster is isolated in its own Azure resource group with its own BareMetal hosts and delegated networking subnet.

Node count determines both compute and storage; there is no shared storage fabric - data is replicated across nodes in the cluster.

NC2 is region-scoped: the cluster is created in one Azure region, and cross-region DR requires a second NC2 cluster in the target region.

The NC2 cluster is placed in a delegated subnet inside the customer VNet, so the customer retains control of the surrounding VNet, peerings, and gateways.

Changing or deleting the delegated subnet after deployment breaks the NC2 management plane and cluster connectivity to Azure.

Guest VM traffic leaves through the VNet and is subject to NSG, UDR, and Azure Firewall inspection just like any other Azure workload.

VNet peering is non-transitive: if NC2 must reach on-premises and a peered spoke, use a hub VNet with a gateway or Azure Virtual WAN.

Private endpoints for Azure PaaS (storage, Key Vault) require matching Private DNS zones linked to the NC2 VNet.

A single Prism Central can register both on-premises and NC2 clusters, giving one inventory, one category taxonomy, and one set of protection policies.

Categories applied to VMs on-premises can drive the same protection policy that replicates to NC2, enabling policy-based DR without per-VM scripting.

Calm projects can target multiple clusters; a blueprint can deploy to on-premises AHV or NC2 AHV by changing the project's target cluster.

Prism Central version must be compatible with every registered cluster's AOS version; upgrade Prism Central first, then clusters within the supported matrix.

Prism Central itself can be hosted on-premises or in NC2; hosting it in NC2 gives resilience if the on-premises site is lost.

RPO equals the replication interval of the protection policy; a 1-hour schedule means up to 1 hour of data loss on failover.

RTO equals detection time plus recovery plan execution plus VM boot and post-boot validation; automation reduces but does not eliminate boot time.

Test failover clones the recovery VMs in an isolated network so production replication continues unaffected.

Planned failover (migration) performs a final sync and powers off the source, giving near-zero data loss; unplanned failover uses the last replicated snapshot.

Recovery plans can change VM IP addresses at failover; the target subnet's DHCP/DNS must be prepared in advance.

BareMetal node hours are the dominant cost and accrue while the cluster exists, regardless of guest VM power state.

Idle clusters should be deleted or scaled down; there is no 'stopped' state that eliminates node billing.

Azure egress to the internet and to on-premises over ExpressRoute is metered separately from compute.

Backup storage in Azure Blob and snapshot replication traffic add incremental cost on top of node hours.

Budgets and cost alerts scoped to the NC2 resource group catch runaway node counts early.