Bug 736419

Summary:	(NetApp CQ209655) RHEL 6.0 DMMP SANboot from alternate controller will not boot with LUNs mapped to host other than SANboot LUN
Product:	Red Hat Enterprise Linux 6	Reporter:	Michael Potyandy <michael.potyandy>
Component:	device-mapper-multipath	Assignee:	Ben Marzinski <bmarzins>
Status:	CLOSED NOTABUG	QA Contact:	Storage QE <storage-qe>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.0	CC:	abdel.sadek, agk, bmarzins, coughlan, ctatman, czhang, dwysocha, fge, heinzm, ichute, mbroz, prajnoha, prockai, rmogen, xdl-apbu-iop-bz, zkabelac
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-01-05 14:59:25 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	720380, 756082

Description Michael Potyandy 2011-09-07 16:24:03 UTC

Description of problem: When booting SANboot RHEL 6.0 DMMP with the SANboot LUN owned by the alternate path on the storage array along with having LUNs mapped from multiple arrays, the OS begins to boot but then hangs reporting "INFO: task jbd2/dm-67-8:3367 blocked for more than 120 seconds." 

Version-Release number of selected component (if applicable):
RHEL 6.0

How reproducible:
The issue occurs everytime when trying to boot the SANboot LUN from the alterate path with additional LUNs mapped.

Steps to Reproduce:
1. Create 80 GB LUN (for SANboot).
2. Install OS to the SANboot LUN.
3. The SANboot LUN as well as 64 additional LUNs (32 from each array) are mapped to the host
3. Host is restarted to configure hba to boot from alternate controller
4. Reboot host.
  
Actual results:
The host begins to boot but hangs with message "INFO: task jbd2/dm-67-8:3367 blocked for more than 120 seconds."

Expected results:
OS boots up without any issues.

Additional info: We are seeing this issue using a QMI8142 Manteo FCoE HBA going to DS3500 and DS5300 arrays; iSCSI using Emulex eRaptor CNA (P/N: 49Y4235) going to two DS3500 arrays; and an IBM HS22 Blade server using a Meteorite (IBM P/N 43W3974) SAS pass-thru adapter going to DS3500 and DS3200 arrays.

Comment 2 Ben Marzinski 2011-09-08 20:16:15 UTC

There were some problems with both device-mapper-multipath and anaconda in RHEL 6.0, which could have caused them. This looks like it could be 644111. Would it be possible for you to retest this with 6.1?

Comment 3 Michael Potyandy 2011-09-08 20:43:00 UTC

We won't be able to try with 6.1 for probably another week or two with any of the same HBAs.  We were able to successfully SANboot from the alternate controller with volumes mapped on RHEL 6.1 using an Emulex fibre channel 8Gb Tetra (LPe1205-CIOv) HBA.

Comment 8 Abdel Sadek 2011-12-06 21:04:07 UTC

Adding IBM.

Comment 10 Michael Potyandy 2011-12-20 21:27:53 UTC

We do not see the issue on RHEL 6.1 or 6.2 using different HBAs/CNAs.  We have successfully booted from the alternate path with additional LUNs mapped using an Emulex fibre channel 8Gb (LPe1205-CIOv), Brocade Wanchese CNA (BR-1020) with FCoE, and 4Gb QLogic (QMI2472) & Emulex (LP1105-BC) HBAs.

Comment 11 Ben Marzinski 2012-01-04 19:43:54 UTC

So, can this be closed?

Comment 13 Michael Potyandy 2012-05-10 21:07:02 UTC

Yes, this can be closed.