Cloud Native Storage (CNS) Frequently Asked Questions for vSphere CSI
search cancel

Cloud Native Storage (CNS) Frequently Asked Questions for vSphere CSI

book

Article ID: 433729

calendar_today

Updated On:

Products

VMware vSphere Kubernetes Service

Issue/Introduction

This article addresses common queries regarding VMware Cloud Foundation (VCF) Cloud Native Storage (CNS) and the vSphere Container Storage Interface (CSI) driver.

Questions - 

Q1: Does the vSphere CSI driver support dynamic provisioning for NFS?
Q2: Why does the csi.vsphere.vmware.com driver fail to bind volumes requesting the ReadWriteMany (RWX) access mode?

Environment

  • vSphere Container Storage Interface (CSI)
  • vSAN File Services
  • VMware vSphere 7.x and 8.x

Resolution

Q1: Does the vSphere CSI driver support dynamic provisioning for NFS?

The short answer is no, if your goal is to use the vSphere CSI driver to dynamically provision native NFS file shares directly to your pods from a standard NFS datastore.

However, there is an important architectural nuance depending on exactly how you intend to consume the storage. The vSphere CSI driver provisions VMDKs (Block storage) by default. To provision file shares (Native File), specific prerequisites must be met.

Here is a breakdown of the supported dynamic provisioning configurations:

Storage Backend / CSI Driver

Access Mode

Dynamic Provisioning Supported?

vSphere CSI (Block)



(Dynamic VMDKs on VMFS, NFS, or vSAN datastores)

ReadWriteOnce (RWO)

Yes.



The CSI driver dynamically creates a VMDK on the underlying datastore (even if it is an NFS datastore) and attaches it to the worker node.

vSphere CSI (Native File)



(NFS file shares from an external array)

ReadWriteMany (RWX)

No.



The vSphere CSI driver cannot dynamically create native file shares on a standard NFS array. (Exception: See vSAN File Services below).

Standard NFS / Vendor CSI



(Directly mounting NFS shares to multiple pods)

ReadWriteMany (RWX)

Yes.



This requires using the storage vendor's specific CSI driver (e.g., Dell PowerScale, NetApp Trident) or the open-source Kubernetes NFS provisioner.

 

Q2: Why does the csi.vsphere.vmware.com driver fail to bind volumes requesting the ReadWriteMany (RWX) access mode?

By design, the standard csi.vsphere.vmware.com driver provisions block-based VMDKs. Block storage can only be safely mounted to a single Kubernetes worker node at a time, meaning it only natively supports the ReadWriteOnce (RWO) access mode.

If a PersistentVolumeClaim (PVC) requests ReadWriteMany (RWX), the vSphere CSI driver will reject it unless it has a mechanism to create and manage a distributed file system.

If your workloads require RWX access, please utilize one of the following supported architectures:

Option 1: Utilize vSAN File Services (VMware Native Solution)

If your underlying storage is a vSAN datastore, you can enable vSAN File Services. When this feature is active, the vSphere CSI driver detects it and can dynamically provision native file shares, successfully fulfilling PVC requests for the ReadWriteMany (RWX) access mode.

Option 2: Utilize a Third-Party Storage Vendor CSI Driver

If you are using an external NFS array (non-vSAN), you must install the specific CSI driver provided by your hardware vendor (e.g., Dell PowerScale CSI, NetApp Trident). By creating a StorageClass that points to the vendor's provisioner instead of the vSphere CSI driver, you can dynamically provision RWX volumes directly from the array.

Additional Information