🚀 How to Fix PVC Size Issues with OpenShift (CRC) and Custom Storage Classes

Are you running into persistent volume issues in OpenShift using CodeReady Containers (CRC)? When provisioning storage using the crc-csi-hostpath-provisioner, you may notice that the PVC (PersistentVolumeClaim) defaults to a large size, such as 99Gi, even though you specified a smaller size in your Helm chart or manifest. This happens because the default storage class uses the WaitForFirstConsumer volume binding mode.

💡 What’s the Problem?
The WaitForFirstConsumer mode means the storage is not provisioned until the pod is scheduled, and the provisioner may be using default values that override your desired PVC size. Let’s fix that by creating a custom storage class with Immediate volume binding.

✅ Steps to Fix the PVC Size Problem

1️⃣ Create a Custom Storage Class with Immediate Binding

Since the default storage class is overriding the size, you can create a new custom storage class with the Immediate binding mode. This ensures that the PVC is provisioned as soon as it is created, and the correct size is allocated.

Here’s a sample configuration for your custom storage class:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: custom-hostpath-storage
annotations:
storageclass.kubernetes.io/is-default-class: "false" # Not a default class
provisioner: kubevirt.io.hostpath-provisioner
reclaimPolicy: Delete # Automatically deletes the volume when the PVC is deleted
volumeBindingMode: Immediate # Provision the volume as soon as the PVC is created
parameters:
storagePool: local

Apply this new storage class by running:

oc apply -f custom-storage-class.yaml

🛠️ Add a Screenshot (Paused)

Here you would add a screenshot of the storage class creation command output for your blog post.

2️⃣ Modify Your Helm Chart to Use the Custom Storage Class

Once the custom storage class is in place, update your Helm chart’s values.yaml to reference it. This ensures that the new PVCs created for your applications will use the custom class.

Update the persistence section of your Helm chart like this:

persistence:
enabled: true
accessModes:
- ReadWriteOnce
size: 2Gi # Specify the size you need
storageClass: "custom-hostpath-storage" # Use the newly created storage class

🛠️ Add a Screenshot (Paused)

Here you would add a screenshot showing the modification in the values.yaml file.

3️⃣ Delete the Existing PVC and Recreate It

If you already have a PVC created with the old storage class and incorrect size, you’ll need to delete it and recreate it with the new storage class.

Run the following command to delete the old PVC:

oc delete pvc my-release-grafana -n default

After deleting the PVC, redeploy your Helm release with the updated values.yaml:

helm upgrade my-release ./your-grafana-chart -n default

This will trigger the creation of a new PVC using the custom-hostpath-storage class with the correct size.

🛠️ Add a Screenshot (Paused)

Here you would add a screenshot of the new PVC being created with the correct size.

4️⃣ Verify the PVC Size

Finally, you’ll want to verify that the new PVC has been created with the correct size (2Gi in this example):

oc get pvc -n default

You should see the new PVC with the size you specified, such as 2Gi.

🛠️ Add a Screenshot (Paused)

Here you would add a screenshot showing the correct size of the new PVC.

🎯 Why This Works:

• Immediate Binding: Using Immediate volume binding ensures that the PVC is created as soon as the request is made, preventing delays and size overrides.

• Custom Storage Class: By creating a custom storage class, you gain more control over the PVC provisioning process, avoiding any potential defaults that might come from the existing crc-csi-hostpath-provisioner storage class.

🔗 Connect with Me:

• 💼 LinkedIn: Rifat Erdem Sahin

• 🐦 Twitter: Rifat Erdem Sahin on Twitter

• 🎥 YouTube: Rifat Erdem Sahin on YouTube

• 💻 GitHub: Rifat Erdem Sahin on GitHub

Let me know if this solution works for you, or if you encounter any further issues!

Reference Repo

Imported from rifaterdemsahin.com · 2025