Previously, Red Hat Enterprise Linux Virtualization 3.4.0 introduced a regression where SCSI scans for FC devices were disabled. As a result, new LUNs on FC servers were not discovered automatically. With this release, the SCSI scan for FC devices has been reintroduced so that new LUNs on FC servers can be discovered automatically.
Description of problem:
After adding new LUNs on FC server, the LUNs are not detected on
hypervisors.
Version-Release number of selected component (if applicable):
All versions since 4.14.0
How reproducible:
Always
Steps to Reproduce:
1. Start a hypervisor connected to FC storage server
2. On the FC stoage server, add new LUN and expose it to the hypervisor
3. Try to edit a FC storage domain or create new one
Actual results:
The new LUN does not appear in the device lists
Expected results:
The new LUN should be listed
Additional info:
In versions before 4.14.0, we used to perform scsi scan, equivalent
to this:
for path in /sys/class/scsi_host/host*/scan
do echo "- - -" > $path
done
This scan was removed in 66c24c1996 (iscsi: Iscsi rescan cleanup),
assuming that iscsiadm -m session --rescan is already doing the scsi
scan. iscsiadm is doing scssi scan, but only for iscsi connections.
This issue was reported in bug 1123637, but we did not detect the missing
scsi scan on FC devices. We fixed this but by introducing FC issue_lip
operation. This fix was disabled later due to bug 1157681, because on
some storage server, issue_lip was disruptive.
Workaround:
Perform manual scsi scan on all fc hosts:
1. Log in to host
2. Run:
for path in /sys/class/fc_host/host*/device/scsi_host/host*/scan; do
echo "- - -" > $path
done
For more details see:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/scanning-storage-interconnects.html
Tested Nir's patch. Tested that FC scan is performed:
- Mapped a new device to the host by FC, then tried to create new FC storage domain. New devices are visible to the host
- Mapped a new device to the host by FC, then tried to edit an existing FC domain. New devices are visible to the host
- Negative: Unmapped a device from the host. fc_scan doesn't hung
Tested with both RHEL6.6 and RHEL7 OS installed on the hosts.
Tested using 2 storage servers: EMC-XtremIO and EMC-VNX
FC LUNs are detected while exposing them without rebooting the host.
Tested the following:
- Exposed new LUN to the host and clicked on 'New' domain. LUN was visible
- Exposed new LUN to the host and clicked on 'Edit' FC domain. LUN was visible
Tested using 2 storage servers:
- EMC XtremIO
- EMC VNX
Verified using rhev 3.5 vt13.1
vdsm-4.16.8.1-2.el6ev.x86_64
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2015-0159.html
Description of problem: After adding new LUNs on FC server, the LUNs are not detected on hypervisors. Version-Release number of selected component (if applicable): All versions since 4.14.0 How reproducible: Always Steps to Reproduce: 1. Start a hypervisor connected to FC storage server 2. On the FC stoage server, add new LUN and expose it to the hypervisor 3. Try to edit a FC storage domain or create new one Actual results: The new LUN does not appear in the device lists Expected results: The new LUN should be listed Additional info: In versions before 4.14.0, we used to perform scsi scan, equivalent to this: for path in /sys/class/scsi_host/host*/scan do echo "- - -" > $path done This scan was removed in 66c24c1996 (iscsi: Iscsi rescan cleanup), assuming that iscsiadm -m session --rescan is already doing the scsi scan. iscsiadm is doing scssi scan, but only for iscsi connections. This issue was reported in bug 1123637, but we did not detect the missing scsi scan on FC devices. We fixed this but by introducing FC issue_lip operation. This fix was disabled later due to bug 1157681, because on some storage server, issue_lip was disruptive. Workaround: Perform manual scsi scan on all fc hosts: 1. Log in to host 2. Run: for path in /sys/class/fc_host/host*/device/scsi_host/host*/scan; do echo "- - -" > $path done For more details see: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/scanning-storage-interconnects.html