| 2022-09-26 13:12:21 |
Rajat Dhasmana |
bug |
|
|
added bug |
| 2022-09-27 03:54:51 |
Rajat Dhasmana |
description |
This issue is in the Fiber channel netapp driver.
In a scenario where NetApp FC has multiple HA pairs deployed (each backed with one or more controllers) that are independent from each other, NetApp driver doesn't filter out the WWPNs it receives from the storage array to create the correct initiator target map.
By providing all the target WWPNs to os-brick, we are not sure which target WWPN can actually access the LUN and if a previous attachment from another HA pair exists, we try to do a narrow scan of that particular HA pair which will fail if the current attachment is from another HA pair (since all HA pairs have different WWPNs).
In summary, NetApp should only create the initiator target map with the WWPNs that actually point to the HA pair which contains the LUN.
Eg: 3 HA pairs each backed with 2 controllers.
HA pair 1 has two HBAs with two WWPNs 1 and 2
HA pair 2 has two HBAs with two WWPNs 3 and 4
HA pair 3 has two HBAs with two WWPNs 5 and 6
If NetApp has created a LUN in HA pair 2 and it wants an attachment to happen, it should filter out only WWPNs 3 and 4, create initiator target map with that and supply to os-brick.
Currently it supplies all WWPNs i.e. (1,2,3,4,5,6)
Failure scenario: If we already have a volume attached from HA pair 1 and we want to attach another volume from HA pair 2, we supply all WWPNs i.e. (1,2,3,4,5,6) but os-brick does a narrow scanning of WWPNs 1 and 2 (since HBTL values of those WWPNs currently exist in the host). |
This issue is in the Fiber channel netapp driver.
In a scenario where NetApp FC has multiple HA pairs deployed (each backed with one or more controllers) that are independent from each other, NetApp driver doesn't filter out the WWPNs it receives from the storage array to create the correct initiator target map.
By providing all the target WWPNs to os-brick, we are not sure which target WWPN can actually access the LUN and if a previous attachment from another HA pair exists, we try to do a narrow scan of that particular HA pair which will fail if the current attachment is from another HA pair (since all HA pairs have different WWPNs).
In summary, NetApp should only create the initiator target map with the WWPNs that actually point to the HA pair which contains the LUN.
Eg: 3 HA pairs each backed with 2 controllers.
HA pair 1 has two HBAs with two WWPNs 1 and 2
HA pair 2 has two HBAs with two WWPNs 3 and 4
HA pair 3 has two HBAs with two WWPNs 5 and 6
If NetApp has created a LUN in HA pair 2 and it wants an attachment to happen, it should filter out only WWPNs 3 and 4, create initiator target map with that and supply to os-brick.
Currently it supplies all WWPNs i.e. (1,2,3,4,5,6)
Failure scenario: If we already have a volume attached from HA pair 1 and we want to attach another volume from HA pair 2, we supply all WWPNs i.e. (1,2,3,4,5,6) but os-brick does a narrow scanning of WWPNs 1 and 2 (since HBTL values of those WWPNs currently exist in the host) and we are not able
to access the LUN (since they exist in WWPNs 3 and 4). |
|
| 2022-09-27 03:55:19 |
Rajat Dhasmana |
description |
This issue is in the Fiber channel netapp driver.
In a scenario where NetApp FC has multiple HA pairs deployed (each backed with one or more controllers) that are independent from each other, NetApp driver doesn't filter out the WWPNs it receives from the storage array to create the correct initiator target map.
By providing all the target WWPNs to os-brick, we are not sure which target WWPN can actually access the LUN and if a previous attachment from another HA pair exists, we try to do a narrow scan of that particular HA pair which will fail if the current attachment is from another HA pair (since all HA pairs have different WWPNs).
In summary, NetApp should only create the initiator target map with the WWPNs that actually point to the HA pair which contains the LUN.
Eg: 3 HA pairs each backed with 2 controllers.
HA pair 1 has two HBAs with two WWPNs 1 and 2
HA pair 2 has two HBAs with two WWPNs 3 and 4
HA pair 3 has two HBAs with two WWPNs 5 and 6
If NetApp has created a LUN in HA pair 2 and it wants an attachment to happen, it should filter out only WWPNs 3 and 4, create initiator target map with that and supply to os-brick.
Currently it supplies all WWPNs i.e. (1,2,3,4,5,6)
Failure scenario: If we already have a volume attached from HA pair 1 and we want to attach another volume from HA pair 2, we supply all WWPNs i.e. (1,2,3,4,5,6) but os-brick does a narrow scanning of WWPNs 1 and 2 (since HBTL values of those WWPNs currently exist in the host) and we are not able
to access the LUN (since they exist in WWPNs 3 and 4). |
This issue is in the Fiber channel netapp driver.
In a scenario where NetApp FC has multiple HA pairs deployed (each backed with one or more controllers) that are independent from each other, NetApp driver doesn't filter out the WWPNs it receives from the storage array to create the correct initiator target map.
By providing all the target WWPNs to os-brick, we are not sure which target WWPN can actually access the LUN and if a previous attachment from another HA pair exists, we try to do a narrow scan of that particular HA pair which will fail if the current attachment is from another HA pair (since all HA pairs have different WWPNs).
In summary, NetApp should only create the initiator target map with the WWPNs that actually point to the HA pair which contains the LUN.
Eg: 3 HA pairs each backed with 2 controllers.
HA pair 1 has two HBAs with two WWPNs 1 and 2
HA pair 2 has two HBAs with two WWPNs 3 and 4
HA pair 3 has two HBAs with two WWPNs 5 and 6
If NetApp has created a LUN in HA pair 2 and it wants an attachment to happen, it should filter out only WWPNs 3 and 4, create initiator target map with that and supply to os-brick.
Currently it supplies all WWPNs i.e. (1,2,3,4,5,6)
Failure scenario: If we already have a volume attached from HA pair 1 and we want to attach another volume from HA pair 2, we supply all WWPNs i.e. (1,2,3,4,5,6) but os-brick does a narrow scanning of WWPNs 1 and 2 (since HBTL values of those WWPNs currently exist in the host) and we are not able
to access the LUN (since that exists in WWPNs 3 and 4). |
|
| 2022-09-28 13:32:37 |
Sofia Enriquez |
cinder: importance |
Undecided |
Low |
|
| 2022-09-28 13:32:56 |
Sofia Enriquez |
tags |
|
drivers fc netapp |
|
| 2022-09-29 15:12:43 |
Nahim Alves de Souza |
cinder: assignee |
|
Nahim Alves de Souza (nahimsouza) |
|
| 2022-11-04 20:18:22 |
OpenStack Infra |
cinder: status |
New |
In Progress |
|
