Bug 130365
| Summary: | Request to include EMC Celerra and iSCSI devices to the black list | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Heather Conway <conway_heather> |
| Component: | kernel | Assignee: | Tom Coughlan <coughlan> |
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | kaufman_susan, perez-kolk_santiago, petrides, riel |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-05-18 13:27:48 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
looks good; can you send a patch with this to the linux-scsi mailinglist as well? Other question: the 2.6 kernel will use the report-luns command IF a device claims scsi3 compliance, if it doesn't claim that but still supports report-luns the prefered method is to blacklist this (instead of the SPARSE/LARGE lun flags). Can you find out if/how this device behaves in this respect ? Yes to both of your questions....thanks! Heather, I overlooked this for U4/U6 (sorry). Fortunately it is not necessary to update the whitelist for the Cisco software initiator. The driver does its own scanning, so the midlayer whitelist is ignored. I have tested sparsely-numbered LUNs on U4 with Celerra, and it works fine without the whitelist entries. I will add the "Celerra iSCSI" to the whitelist in U5/U7 anyway, just in case anyone tries to use the hardware initiators. They will presumably use the midlayer scanning. Would you please explain what you mean by "non-existing LUN" above? What are non-existing LUNs, and why do we need a whitelist entry for them? Heather, Can you look in to my question about "non-existing LUN" above? Tom A fix for this problem has just been committed to the RHEL3 U5 patch pool this evening (in kernel version 2.4.21-27.17.EL). An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-294.html |
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; EMC IS 55; .NET CLR 1.0.3705; .NET CLR 1.1.4322) Description of problem: I would like to request that Red Hat consider incorporating the following code to the SCSI black list in the RHEL 2.1 and RHEL 3.0 kernels. This code will allow LUN skipping, correct identification, and large LUN identification of EMC Celerra and iSCSI devices. for existing LUN: {"EMC", "Celerra iSCSI", "*", BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_FORCELUN} for non-existing LUN: {"EMC", "iSCSI", "*", BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_FORCELUN} Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: When attaching to EMC Celerra/iSCSI devices, this code should be added to the v2.4.x SCSI black list to allow for correct identification of the devices. Additional info: