Description of problem: Goutham from RHOS Storage engineering was already involved in ongoing escalation for one of our customers and knows context. Shortly speaking, MAC address used by NetApp storage to host shares is not static and impossible to predict. As a result, a manila:share port created by Manila has a MAC address that doesn't match real MAC address used by storage. This situation causes problems inside OVN because it expects different MAC address to be used by VMs when they are communicating with storage. As a result, traffic is dropped. One of workarounds proposed by OVN team is to disable Neutron port. There is existing issue https://issues.redhat.com/browse/FDP-697 reported for OVN, I am reporting this bug to ask Manila team to check if it is possible to do something on their side and maybe discuss this problem with OVN engineers. For example, disabling the port in Neutron fixes this problem and if port is only created for IPAM purposes, then maybe disabling it will help? Or this is not going to work because we rely on OVN to create some security groups? Version-Release number of selected component (if applicable): RHOSP 17.1 Steps to Reproduce: 1. Create a share with NetApp backend 2. Try to ping share from some VM Actual results: no network connectivity Expected results: VM is able to reach NetApp storage Additional info: there is extensive discussion in attached support case
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 (RHOSP 17.1.4 bug fix and enhancement advisory), 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/RHBA-2024:9974