Description of problem: when using a LVM LogicalVolume as LocalVolume devicePath [0]. Sample config below (where /dev/elasticsearch/elasticsearch is the LVM LogicalVolume): $ oc get localvolume -n local-storage es-disks -o json | jq .spec.storageClassDevices [ { "devicePaths": [ "/dev/elasticsearch/elasticsearch" ], "fsType": "ext4", "storageClassName": "es-disks", "volumeMode": "Filesystem" } ] This ends up Version-Release number of selected component (if applicable): Actual results: - The LocalVolume PV points to an underlying /mnt/local-storage/${StorageClassName}/dm-X path, instead of the /dev/elasticsearch/elasticsearch LogicalVolume. - /dev/elasticsearch/elasticsearch has different /mnt/local-storage/${StorageClassName}/dm-X symlinks pointing to the same /dev/elasticsearch/elasticsearch LogicalVolume - Different PersistentVolumes can be provisioned pointing to different /mnt/local-storage/${StorageClassName}/dm-X symlinks, under the same /dev/elasticsearch/elasticsearch LogicalVolume, pointing to the same underlying data. Expected results: - Have one and only PV per LocalVolume object. Additional info: - Logs dumps and outputs to follow. --- [0] https://github.com/openshift/local-storage-operator/blob/release-4.5/deploy/cr.yaml#L10
*** Bug 1892197 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.5.23 security and bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:5359