- Contact OpenEBS Community for support.
- Search for similar issues added in this troubleshooting section.
- Search for any reported issues on StackOverflow under OpenEBS tag
Created a PVC using localpv-device / localpv-hostpath storage class. But the PV is not created and PVC in Pending state.
The default localpv storage classes from openebs have
volumeBindingMode: WaitForFirstConsumer. This means that only when the application pod that uses the PVC is scheduled to a node, the provisioner will receive the volume provision request and will create the volume.
Resolution: Deploy an application that uses the PVC and the PV will be created and application will start using the PV
Application pod that uses localpv device is stuck in
Pending state with error
Troubleshooting: Check if there is a blockdevice present on the node (to which the application pod was scheduled,) which matches the capacity requirements of the PVC.
If matching blockdevices are not present, then the PVC will never get Bound.
Resolution: Schedule the application pod to a node which has a matching blockdevice available on it.
Pending BDCs created by localpv provisioner, even after the corresponding PVC has been deleted.
Resolution: LocalPV provisioner currently does not delete BDCs in Pending state if the corresponding PVCs are deleted. To remove the stale BDC entries,
- Edit the BDC and remove the
- Delete the BDC
The BDC created by localpv provisioner (bdc-pvc-xxxx) remains in pending state and PVC does not get Bound
Troubleshooting: Describe the BDC to check the events recorded on the resource
The following are different types of messages shown when the node on which localpv application pod is scheduled, does not have a blockdevice available.
- No blockdevices found
It means that there were no matching blockdevices after listing based on the labels. Check if there is any
block-device-tag on the storage class and corresponding tags are available on the blockdevices also
- No devices with matching criteria
It means that the there are no devices for claiming after filtering based on filesystem type and node name. Make sure the blockdevices on the node
have the correct filesystem as mentioned in the storage class (default is
- No devices with matching resource requirements
It means that there are no devices available on the node with a matching capacity requirement.
To schedule the application pod to a node, which has the blockdevices available, a node selector can be used on the application pod. Here the node with hostname
svc1 has blockdevices available, so a node selector is used to schedule the pod to that node.