Nutanix Volume Groups and CSI Behavior
When a Kubernetes PersistentVolumeClaim (PVC) is created, the Nutanix CSI driver (csi.nutanix.com) provisions a Nutanix Volume Group (VG) in the storageclass specified. If that storageclass is backed by FlashArray, the resulting Persistent Volume is ultimately backed by corresponding FlashArray Kublock volumes provisioned via AOS. The Nutanix CSI driver manages the full lifecycle of these Volume Groups, including provisioning, attachment to Kubernetes worker node VMs, expansion, snapshot creation, and restore operations.
Supported CSI and Storage Operations
The following operations are supported when using FlashArray-backed storage containers with Nutanix CSI:
| CSI/Storage Operation | Supported with FlashArray? | Notes |
|---|---|---|
| PVC Create/Delete | Yes | Dynamically provisions/deletes Nutanix Volume Groups |
| PV Binding | Yes | Automatic binding via Kubernetes |
| Attach / Detach | Yes | Volume Group attached to / removed from worker node VM |
| Mount / Unmount | Yes | Filesystem mounted inside pod |
| Pod Restart with Volume | Yes | Remount occurs automatically |
| Pod Migration Across Nodes | Yes | Triggers detach/attach cycle |
| Worker Node Scale-Up | Yes | New nodes attach PVs normally |
| Worker Node Scale-Down | Yes | PVs detach before VM deletion |
| Worker Node Reboot | Yes | Volumes reattach after recovery |
| Online Volume Expansion | Yes | Filesystem resized automatically |
| CSI Snapshot Create | Yes | Supported |
| CSI Snapshot Restore | Yes | Creates new PVC from snapshot (no in-place overwrite) |
| Velero Backup / Restore | Yes | Supported |
Volume Access Modes
FlashArray-backed CSI volumes are block devices. The following access modes apply:
| PVC Access Mode | Supported | Notes |
|---|---|---|
| ReadWriteOnce (RWO) | Yes | Primary access mode |
| ReadOnlyMany (ROX) | Yes | Multiple nodes may mount the volume in read-only mode (no concurrent writes) |
| ReadWriteMany (RWX) | No | Block storage limitation; generally requires file-based storage |
Hypervisor-Attached vs Guest-Attached Volumes
NKP supports two CSI attachment models:
-
Guest-Attached (default)
-
Hypervisor-Attached
Cluster creation flag example:
--csi-hypervisor-attached-volumes=false
Support & Recommendation Matrix
| Mode | Supported | Recommended | Use Case |
|---|---|---|---|
| Guest-Attached | Yes | Yes | General workloads |
| Hypervisor-Attached | Yes | Conditional | Latency-sensitive DB / benchmarking |
Recommendation: Guest-Attached vs Hypervisor-Attached Volumes
For most NKP deployments using FlashArray-backed storage, guest-attached volumes are the recommended default.
Guest-attached volumes provide:
-
Cleaner scaling and node mutation workflows
-
Better alignment with Kubernetes automation
-
Faster and more predictable recovery during AHV host failure
Because attachment occurs at the NKP worker node VM level, failover aligns closely with Kubernetes pod lifecycles.
Hypervisor-Attached (Validate before Using)
Hypervisor-attached volumes are supported and may be appropriate for more performance/latency-sensitive workloads.
However:
-
Performance differences are workload-dependent.
-
Customers should perform internal benchmarking with their specific applications before selecting this mode.
-
During AHV host failure or maintenance operations, recovery can take longer because the volume must be reconciled at the hypervisor layer rather than the VM layer.
NKP Persistent Volume Filesystem Support
Nutanix CSI presents Persistent Volumes as block devices to the Kubernetes worker node. The filesystem (ext4 or xfs) is created and managed at the guest OS level.
Both ext4 and xfs are supported on the FlashArray.
Nutanix and FlashArray do not require or mandate a specific filesystem for CSI-provisioned volumes.
Persistent Volume Expansion
-
Online volume expansion is supported.
-
Filesystem resize occurs automatically inside the pod when the PVC is expanded.