Describe the issue: - Need to clarify how multipath is supported in ODF Describe the task you were trying to accomplish: - We have customers that would like to have documented if/how multipath is supported as devices to be used with ODF. Suggestions for improvement: - According to internal discussion, we should add a statement that clearly says how is multipath supported with ODF Document URL: Chapter/Section Number and Title: Product Version: - ODF 4.11 - OCP 4.11 Environment Details: Any other versions of this document that also needs this update: Additional information: As per discussion in the email thread: ODF is a consumer of PVs that are presented to OCP, so if for example, the PVs come from an FC san LSO configuration or from the SC of a CSI driver , ODF will consume those PVs to deploy the ODF bits. When using SAN FC Luns with OCP/ODF, we have to take care of the Multipath configuration in Red Hat CoreOS, the recommended path is to use the CSI driver from the storage provider, it will take care of the mpath configuration and also the support will come from the third-party storage provider, if using the CSI driver is not possible you can use LSO with multipath, but you need to use LocalVolume Object, so you can't configure ODF/LSO via the UI. For the UI issue, I've logged this BZ https://bugzilla.redhat.com/show_bug.cgi?id=2182351 Support for LSO and multipath will come from the OCP storage team.
With mutipath conf configured as described in kcs, osds never loose the path ( pod to disk ) on mpath scan during node reboot. Behavior mirrors a default scsi deployment. Tested and still running in my lab. It has remained persistent following hard node reboots + entire cluster shutdown + rolling mc chrony config + update OCP/ODF to 4.13 Solution was created to address a IBM customer with multipath already configured on the nodes, customer tested and is happy with the result. Assisted by storage SME @bhull for multipath config. https://access.redhat.com/solutions/7014307 I can retrieve the customer case info if needed.
*** Bug 2211762 has been marked as a duplicate of this bug. ***