ReadWriteMany PVC Failure for a Shared Media Scratch Directory
A developer platform team deploys a shared media-processing application on NKP. Three replicas on three worker nodes must read and write the same 2 TiB scratch directory concurrently. The team creates a PersistentVolumeClaim with accessModes: ReadWriteMany using the default Nutanix CSI storage class backed by Nutanix Volumes. The PVC stays Pending, and events report that the access mode is not supported. A previous 500 GiB ReadWriteOnce volume worked for a single pod. The cluster has the Nutanix CSI driver installed but no Nutanix Files share or NFS storage class configured. The application uses POSIX file locking, writes large temporary files, and must survive pod rescheduling on any worker. Retention is seven days, and the team wants snapshots before each release.
1. Explain why the PVC cannot be satisfied and what the access-mode failure does and does not tell you about capacity and CSI health.
Read the worked answer
The default Nutanix CSI storage class backed by Nutanix Volumes provisions block volumes. Block volumes are attached to one node at a time and are presented as ReadWriteOnce or ReadWriteOncePod, not ReadWriteMany. The provisioner rejects the request because the requested access mode is outside what that driver and volume type support. This is not a capacity shortage and not evidence that the CSI driver is unhealthy: the earlier ReadWriteOnce volume proves provisioning and attachment can work.
The event is specific to the access mode and storage class. The team should confirm which provisioner the storage class names, whether it is the block CSI driver or a file-services driver, and whether a default class is silently being used. A common mistake is to assume that a large block volume can be mounted read-write by multiple nodes; AHV will not attach the same block volume to multiple workers for concurrent writes. The correct fix is to select a storage backend whose access mode matches the workload, not to force the PVC with a different access mode that the application cannot safely use.
2. Design a storage approach for the shared scratch directory. Compare Nutanix Files with NFS, an in-cluster NFS server on a block volume, and object storage, using the application requirements.
Read the worked answer
The application needs concurrent POSIX read-write access, file locking, large temporary files, and rescheduling to any worker. Nutanix Files with an NFS export and a Files-backed storage class is the natural fit. It provides ReadWriteMany, is not tied to a single worker, supports snapshots through the storage layer, and keeps the data independent of pod placement. The team must size the file server, create the share and export policy, and validate locking and throughput with a representative workload.
An in-cluster NFS server on a ReadWriteOnce block volume can provide ReadWriteMany to the pods, but it introduces a single pod as the data path and a potential single point of failure. It may be acceptable for scratch data if the NFS pod is protected by a controller and the volume can be reattached, but it is operationally weaker and locking semantics depend on the NFS implementation. It also complicates snapshots and rescheduling.
Object storage is excellent for durable artifacts but not for POSIX scratch with file locking and random writes. It would require application changes. Use object storage for final outputs and retention, not for the live scratch directory. The recommendation is Nutanix Files for the shared directory, with lifecycle cleanup and snapshot policy aligned to the seven-day retention.
3. Outline the migration and validation steps, including how snapshots and release rollbacks should work.
Read the worked answer
Create the Nutanix Files share, export it only to the NKP worker network, and define a Files-backed storage class with ReadWriteMany. Provision a new PVC and mount it into a test deployment. Copy a representative dataset, then run concurrent writers from three pods on different nodes. Validate POSIX locking, large-file throughput, small-file metadata operations, and behavior when a pod is rescheduled. Confirm the application does not depend on block-device semantics or fixed volume IDs.
For cutover, stop writes, perform a final copy, update the deployment to the new PVC, and start the application. Keep the old block volume read-only until validation completes. For release snapshots, use the storage-layer snapshot capability that matches the Files share, or a coordinated application quiesce plus snapshot. Document that a snapshot restores to a new PVC and that the application must be pointed at it; do not assume an in-place rollback. Test one restore into a separate namespace. Set retention and cleanup so seven-day scratch data does not consume capacity indefinitely, and monitor share capacity and inode usage.