Nutanix NCP-US cheat sheet

Nutanix Unified Storage (NUS) delivers three data services on one distributed platform: Files (SMB/NFS), Objects (S3-compatible), and Volumes (iSCSI block).

All three services are built on Nutanix AOS Distributed Storage Fabric (DSF); data is striped across CVMs and protected by RF2/RF3 or erasure coding, not by RAID arrays.

Files and Objects are served by dedicated File Server VMs (FSVMs) and Object Storage VMs respectively; Volumes are served directly through the AOS iSCSI target (VSA/ABS).

A Prism Central instance is required to deploy and manage Files and Objects; Prism Element alone cannot create file servers or object stores.

NUS licensing is capacity-based per service tier; Files and Objects are licensed separately from AOS, and Objects requires a valid Objects license before bucket creation.

Nutanix Files supports SMB 2.1/3.x and NFS v3/v4.1; the same share namespace can be exported over SMB and NFS simultaneously.

Objects exposes an S3-compatible API with bucket policies, versioning, object locking, and WORM; it is not a full AWS S3 clone - some advanced S3 APIs are unsupported.

Volumes present LUNs over iSCSI to external hosts; each Volume Group can contain multiple vDisks and is attached to one or more initiators via IQN allowlists.

Data Services IP (a virtual IP) fronts Files and Objects access; clients should resolve file server and object endpoints to this VIP rather than individual CVM IPs.

Deploy a File Server from Prism Central: choose Files > File Servers > Create, then size the FSVM (vCPU/RAM) and select the storage container and network.

Each File Server is a scale-out pair or larger of FSVMs; a minimum of one FSVM is allowed but two or more are recommended for HA and performance.

Share types: Standard (SMB/NFS), Distributed (multiple FSVMs serve one namespace for scale), and Home (per-user shares auto-created on login).

SMB share permissions use a share-level ACL plus NTFS-style file ACLs; NFS exports use host/IP allowlists with root squash and read-write or read-only modes.

NFSv4.1 with Kerberos (krb5, krb5i, krb5p) provides authentication and integrity/privacy; without Kerberos, NFS relies on IP-based trust.

SMB signing and SMB encryption can be enforced per share; SMB 1.0 should be disabled because it is deprecated and insecure.

Quotas can be set at share level (hard limit on total share usage) or user/group level (per-identity limit) and are enforced by the FSVM.

Share snapshots are taken from Prism Central and can be scheduled; snapshots are crash-consistent and can be cloned to create new shares.

AD/LDAP integration is configured at the file server level; the file server joins the domain and uses AD for SMB authentication and identity mapping.

Objects is deployed as an Object Store from Prism Central; you select the number of Object Storage VMs (OSVMs) and the storage container.

Access is controlled via access keys (access key ID + secret access key) created per user or per object store; keys are used with S3 SigV4 signing.

Bucket policies are JSON documents granting/denying principals (users, keys) actions such as s3:GetObject or s3:PutObject on bucket or object ARNs.

Bucket versioning retains prior object versions; object locking (WORM) requires versioning and prevents deletion for a retention period.

Objects supports lifecycle policies to expire or transition objects; lifecycle rules act on current or noncurrent versions.

S3 compatibility is partial: core CRUD, multipart upload, presigned URLs, and ACLs are supported; some advanced APIs (e.g., certain replication or analytics calls) are not.

The S3 endpoint is the Object Store's Data Services IP with the appropriate port; clients must use path-style or virtual-hosted-style addressing consistent with the endpoint.

Object Store capacity and erasure coding are configured at deployment; objects are chunked and distributed across OSVMs for durability.

Objects integrates with Prism Central RBAC; object store users are separate from Prism users and are managed under the object store's user list.

A Volume Group is a collection of vDisks presented as iSCSI LUNs; it is created in Prism Element or Prism Central and attached to initiators.

Each iSCSI initiator is identified by its IQN (e.g., iqn.1991-05.com.microsoft:host); the Volume Group allowlist must include the initiator IQN.

CHAP authentication can be enabled per Volume Group (one-way or mutual); credentials must match on the host initiator.

The iSCSI target portal is a CVM IP (or the Volumes data services IP) on TCP port 3260; multipath I/O across multiple CVMs improves availability and throughput.

Volumes are exposed as block devices; the guest OS formats them with its own filesystem (NTFS, ext4, XFS) - Nutanix does not format the LUN.

Volume Groups can be attached to AHV VMs directly (via the VirtIO/SCSI adapter) or to external hosts over iSCSI.

Snapshots of Volume Groups are taken at the vDisk level and are crash-consistent; they can be cloned to create new Volume Groups.

Thin provisioning is default; capacity is consumed as data is written, and Volume Group size is bounded by the storage container.

For external hosts, ensure the host's iSCSI service is running, discovery is pointed at the target portal, and LUN masking matches the initiator IQN.

Nutanix snapshots are metadata-based point-in-time copies; they are space-efficient and do not copy data until blocks change.

Snapshot schedules are defined in protection domains (Prism Element) or via Prism Central policies with RPO and retention settings.

Crash-consistent snapshots capture the VM/volume state without guest quiescing; application-consistent snapshots require VSS or guest scripts.

Async replication sends snapshots to a remote cluster at the RPO interval; synchronous replication is available for metro-level RPO zero on supported configurations.

Protection domains group VMs/volume groups and define the replication schedule and retention; a remote site must be registered as a replication target.

Nutanix DR (Leap) uses Prism Central to orchestrate failover/failback across sites with recovery plans and runbooks.

Files and Objects have their own snapshot/replication mechanisms; file server snapshots and object store replication are configured separately from VM protection.

Snapshot retention is a count or time-based policy; exceeding retention prunes the oldest snapshots automatically.

Restore options include reverting a VM/volume to a snapshot, cloning a snapshot to a new entity, or file-level restore from a file server snapshot.

Prism Central and Prism Element dashboards show cluster IOPS, latency, throughput, and capacity; per-VM and per-container metrics drill down further.

Nutanix Insights (or Prism Central analysis) surfaces anomalies, capacity forecasts, and configuration best-practice violations.

For Files, check FSVM health, share-level IOPS/latency, and SMB/NFS client errors; FSVM CPU or network saturation is a common bottleneck.

For Objects, monitor OSVM health, bucket request rates, and 4xx/5xx error rates; 403 errors usually indicate access key or bucket policy misconfiguration.

For Volumes, verify iSCSI session state on the host (iscsiadm -m session), target portal reachability on 3260, and CHAP/IQN mismatches.

Common NUS issues: Data Services IP unreachable, DNS misconfiguration, expired AD machine account, and storage container full.

Use ncli, acli, and Prism APIs for CLI-level diagnostics; logs are collected via NCC (Nutanix Cluster Check) for support cases.

Latency is measured at the CVM (storage) and at the guest (application); high CVM latency with normal guest latency suggests a host-side issue.

Capacity alerts should be acted on before the storage container reaches its reserved threshold, which can block writes.

Prism Central RBAC uses roles (e.g., Prism Admin, Prism Viewer, Self-Service Admin) bound to users/groups from AD/LDAP; least privilege is enforced by role scope.

Nutanix Files supports SMB signing, SMB encryption, and NFS Kerberos (krb5/krb5i/krb5p) to protect data in transit.

Objects supports bucket policies, ACLs, access keys, and object locking (WORM) for compliance; versioning must be enabled for object locking.

Data-at-rest encryption uses Nutanix Self-Encrypting Drives (SEDs) or software-based encryption managed via Prism; keys are managed by the cluster or external KMS.

Audit logs in Prism Central record administrative actions; object store access logging can record S3 requests for compliance.

AD integration for Files requires a service account with appropriate privileges; the file server computer account must not expire.

Network segmentation: place Data Services IP, iSCSI portals, and client networks on appropriate VLANs; restrict iSCSI access via initiator allowlists and CHAP.

Compliance features include WORM/object lock, snapshot retention policies, and immutable backups; retention settings must meet the applicable regulatory period.

Disable legacy protocols (SMB 1.0, unauthenticated NFS) and rotate access keys and CHAP secrets periodically.