Security Platform Deployment Fails Due to CSI Volume Attachment Errors with NFS Datastore
Article ID: 399721
Updated On:
Products
Issue/Introduction
Deployment of Security Platform fails during the Deploy platform task due to volume attachment failures for multiple pods. The CSI driver is unable to attach volumes, as they are not recognized as CNS (Cloud Native Storage) volumes. You will see the below error on SSP Deployment ScreenSecurity Platform :
Failed 1/2 tasks: [Deploy platform]: 16 deployments (authelia, authserver, cluster-api, common-agent, debian-runner, druid-broker, druid-coordinator, druid-router, minio, postgres-ha-pgpool, pulsar, security-goruntime, si-service, telemetry, trust-manager) & 1 statefulset (druid-historical, druid-middle-manager, fluentbit, kafka-controller, minio, nats-config, 0, 0) and 1 (postgres-ha-postgresql, redis-cluster, zookeeper), 1 daemonset (nsx-platform-fluent-bit) false.
This results in multiple pods (such as authelia, authserver, cluster-api) being stuck in a Pending state.
CSI logs (kubectl -n vmware-system-csi logs -l app=vsphere-csi-controller -c csi-attacher ) contain the following error :
Failed to attach disk ... fault: "Volume ... is not registered as a CNS Volume."
The /var/log/vmware/vsan-health/vsanmgmt.log on the vCenter shows CnsNotRegisteredFault errors for the volume IDs in question.
error vsanvcmgmtd[2103425] [vSAN@6876 sub=Workflow opID=63343fc6] Workflow current action has fault (vim.fault.CnsNotRegisteredFault) {
--> faultCause = (vmodl.MethodFault) null,
--> faultMessage = <unset>,
--> reason = "The input volume 40cf37c4-d3a7-4f00-b8d8-546b261b66e5 is not registered as a CNS volume.",
--> volumeId = (vim.cns.VolumeId) {
--> id = "40cf37c4-d3a7-4f00-b8d8-546b261b66e5"
--> }
--> msg = ""
--> }
2025-05-16T15:05:21.778+02:00 info vsanvcmgmtd[2103425] [vSAN@6876 sub=Workflow opID=63343fc6] Workflow Attach volume completed for vim.Task:task-9144196
2025-05-16T15:05:21.778+02:00 info vsanvcmgmtd[2103425] [vSAN@6876 sub=CnsTask opID=63343fc6] Attach volume completed: task-9144196
2025-05-16T15:05:21.780+02:00 info vsanvcmgmtd[2103402] [vSAN@6876 sub=CnsCatalogSvc opID=63343fc5] The datastore datastore-1970252 is granted priviledge for VSPHERE.LOCAL\ssp-op-545b2a24
2025-05-16T15:05:21.780+02:00 info vsanvcmgmtd[2103402] [vSAN@6876 sub=Workflow opID=63343fc5] Attach volume task started
2025-05-16T15:05:21.780+02:00 info vsanvcmgmtd[2103402] [vSAN@6876 sub=FcdService opID=63343fc5] FcdService AttachDisk: volumeId=9e94cb90-a086-4e3b-9c67-20a1f2fb1417, vmRef=vim.VirtualMachine:vm-3812030
2025-05-16T15:05:21.780+02:00 error vsanvcmgmtd[2103402] [vSAN@6876 sub=Workflow opID=63343fc5] Workflow current action has fault (vim.fault.CnsNotRegisteredFault) {
--> faultCause = (vmodl.MethodFault) null,
--> faultMessage = <unset>,
--> reason = "The input volume 9e94cb90-a086-4e3b-9c67-20a1f2fb1417 is not registered as a CNS volume.",
--> volumeId = (vim.cns.VolumeId) {
--> id = "9e94cb90-a086-4e3b-9c67-20a1f2fb1417"
--> }
--> msg = ""
--> }
These errors repeat for multiple volumes
Additionally:
The datastore is not visible under vSphere > Monitor > Cloud Native Storage > Volumes.
VMs on the same datastore continue to work, indicating the issue is specific to CNS registration and not general storage access.
Environment
vSphere 8.0 Patch 03 (p03)
Security Platform (SSP/SSPi) 5.0
Cause
The persistent volumes were not registered as CNS volumes. Datastore is not CNS-compliant or is improperly configured for CNS. As a result, volumes dynamically provisioned by CSI could not be attached to nodes, leading to pod failures.
Resolution
Follow the below KB to perform a CNS volume re-sync operation:
CNS volumes may be removed from the cache following a VSAN partition in vCenter 8.0.3
https://knowledge.broadcom.com/external/article?articleNumber=390695
This issue is resolved in vSphere 8.0 Patch 05.
Workaround
No direct workaround is available unless the datastore is CNS-compliant.
Alternative: Use a CNS-compatible datastore (e.g., vSAN or certified CNS-enabled NFS).
Feedback
