Verify PX-CSI installation on ARO cluster

Verify Pods & Storage Cluster status


oc get pods -n portworx | grep -E 'px|pure-csi'
oc get storagecluster -n portworx

All PX-CSI pods should be Running, and the Storage Cluster phase should be Online/Running.

StorageClass configuration

PX-CSI automatically creates a set of default StorageClasses (e.g. px-pure-csi-*).


oc get sc

You can use these default or create custom StorageClasses for specific Everpure Cloud Dedicated volume policies (size, access modes, snapshots, etc.).


#Example StorageClass for FlashArray / Everpure Cloud Dedicated

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: px-pure-csi-sc
provisioner: pxd.portworx.com          # same driver you already have
parameters:
  backend: pure_block                  # REQUIRED for FlashArray / CBS block
  csi.storage.k8s.io/fstype: xfs       # or ext4 if you prefer
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate  		# Immediate or WaitForFirstConsumer, as you prefer

Save this StorageClass specification into file (for example px-pure-csi-sc.yaml and import it into the cluster:


oc apply -f px-pure-csi-sc.yaml

Note: For PX-CSI + Everpure Cloud Dedicated/FlashArray, WaitForFirstConsumer voume binding mode is usually preferred when you care about topology or multipool placement, while Immediate is useful for simple labs/tests where you want the volume created as soon as you create the PVC.

StorageClass volumeBindingMode Note

Immediate

Volume is created and bound to the PVC as soon as the PVC is created, regardless of any pod.
Pros: simple, fast provisioning.
Cons: scheduler may pick a node later that's a poor fit (e.g. wrong zone), or can't mount the volume; less topology-aware.

WaitForFirstConsumer

PVC stays Pending until a pod that uses it is scheduled.
Kubernetes first chooses a node for the pod, then the storage plugin provisions the volume with knowledge of that node's topology (zone, region, labels).
Pros: correct / optimal placement for zonal storage and topology-aware backends; avoids orphan volumes in the wrong zone.
Cons: looks “stuck” in Pending until a pod exists and can be scheduled.