Red Hat Bugzilla – Bug 1255232
FCoE BFS Installation: LUN not handled by device mapper even after discovery through both the ports of the adapter
Last modified: 2015-09-08 06:51:05 EDT
Created attachment 1065076 [details]
LUN discovered as two different disks
Description of problem:
While performing FCoE BFS installation using dual port adapter(BCM 57810), LUN (LUN ID 0) discovery is successful through both the ports. After discovery, LUN is seen as two different disks and not handled by device mapper
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure the server/adapter (dual port) for FCoE BFS
2. Provision the LUN from the storage array
3. Mount the ISO and start the installation and follow the on screen instruction
4. In the Installation Summary screen, Click on Installation Destination
5. In the Installation Destination screen, Click on "Add a disk"
6. Click on "Add FCoE SAN
7. Select the respective port and click on "Add FCoE Disks", repeat the step for the other port as well
LUN gets discovered through both the ports and and not handled by device mapper (multipath)and seen as two different disks. Please see the attachment "LUN-discovery.png"
LUN should get discovered through both the ports and should be handled by device mapper (multipath)
Able to make the device mapper to handle the LUN by again performing the step 6 and step 7. Please see the attachment "lun-handled-by-device-mapper.png"
Created attachment 1065077 [details]
after performing workaround, LUN is handled by multipath
I'm going to reassign this to blivet to see what their opinion is on this.
Blivet folks, if you think that this is happening because multipath isn't doing something correctly, just let me know what it is, and reassign it back.
Please attach the logs from /tmp/*log as individual text/plain attachments to this bug. Grab them after you have repeated steps 6 and 7 so we can see what things look like before and after your workaround.
(In reply to Brian Lane from comment #5)
> Please attach the logs from /tmp/*log as individual text/plain attachments
> to this bug. Grab them after you have repeated steps 6 and 7 so we can see
> what things look like before and after your workaround.
I am unable to reproduce this issue. Hence closing it for now. Will re-open the issue with the requested logs if encounter again.