CSI Fails to Initialize on OpenShift 4.16.39 Due to Malformed Configuration in vsphere-config-secret

Products

• VMware vCenter Server

Issue/Introduction

After deploying CSI 3.4 on OpenShift 4.16.39, PersistentVolumeClaims remained in Pending state. CSI controller logs showed configuration parsing errors, and no volumes were visible in vCenter. One key error was:

“error while reading config file: unknown escape sequence”

Additionally, provisioning attempts failed with:

“failed to provision volume with StorageClass “vmware-csi-sc”: rpc error: code = Internal desc = failed to get shared datastors in kubernetes cluster: Error: NoPermission”

Environment

VMware vCenter Server

Cause

The root cause was malformed input in the vsphere-config-secret. Specifically:

• The user field contained an unescaped backslash, such as domain\user, which YAML parsing treated as an invalid escape sequence.
• The [VirtualCenter "<FQDN>"] section had not been replaced with the actual vCenter FQDN or IP address.
• The CSI service account being used lacked proper permissions in vSphere to access CNS (Cloud Native Storage), resulting in provisioning errors.

Resolution

Multiple changes were made to correct the configuration and permissions:

• The backslash in the user field was escaped properly as domain\\user
• The [VirtualCenter "<FQDN>"] section was updated with the actual hostname or IP address of the vCenter instance
• To validate the configuration, the CSI driver was temporarily configured to use a vSphere administrator account with full privileges
• After confirming CSI functionality, the user began work on narrowing permissions appropriately for the service account

Following these fixes, CSI controller and node pods entered Running state. PVCs were successfully bound, and the corresponding volumes were visible in vCenter. Dynamic provisioning worked as expected, and CSI driver initialization completed without further error.