RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1255232 - FCoE BFS Installation: LUN not handled by device mapper even after discovery through both the ports of the adapter
Summary: FCoE BFS Installation: LUN not handled by device mapper even after discovery ...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: python-blivet
Version: 7.2
Hardware: Unspecified
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Blivet Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-20 04:22 UTC by Vishnu Kumar
Modified: 2021-09-03 14:10 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-08 10:51:05 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
LUN discovered as two different disks (88.55 KB, image/png)
2015-08-20 04:22 UTC, Vishnu Kumar 		no flags Details
after performing workaround, LUN is handled by multipath (88.70 KB, image/png)
2015-08-20 04:24 UTC, Vishnu Kumar 		no flags Details
View All

Description Vishnu Kumar 2015-08-20 04:22:59 UTC 
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):


How reproducible:
100%

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


Actual results:
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"


Expected results:
LUN should get discovered through both the ports and should be handled by device mapper (multipath)

Workaround:
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"
Comment 1 Vishnu Kumar 2015-08-20 04:24:15 UTC 
Created attachment 1065077 [details]
after performing workaround, LUN is handled by multipath
Comment 4 Ben Marzinski 2015-08-20 18:45:31 UTC 
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.
Comment 5 Brian Lane 2015-08-24 16:49:27 UTC 
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.
Comment 6 Vishnu Kumar 2015-09-08 10:51:05 UTC 
(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.

Brian,

I am unable to reproduce this issue. Hence closing it for now. Will re-open the issue with the requested logs if encounter again.
Note You need to log in before you can comment on or make changes to this bug.