Description of problem: On hosts with HP Smart Array controllers, entries similar to the following are seen in '/var/log/messages'; Aug 20 10:33:20 rhev-host1 kernel: scsi: host 0 channel 3 id 0 lun4194304 has a LUN larger than allowed by the host adapter This is not an error message. It is caused by scanning an HP Smart Array controller for luns, i.e. the same error will occur if you echo "- - -" to '/sys/class/scsi_host/host*/scan'. However, VDSM is writing "- - -" to '/sys/class/scsi_host/host*/scan' in 'iscsi.py' when it performs a rescan, which causes the HP Smart Array controller (in the above example channel 3 on host 0) to scan for luns and generate the above message. This is reproducible. If however "0 - -" is written, then no such message will occur. Also, if 'rescan-scsi-bus.sh' is executed no such message will occur. Version-Release number of selected component (if applicable): RHEV 3.x RHEL 6.5 hosts RHEV-H 6.5 hosts How reproducible: Every time on a system with an HP Smart Array controller. Steps to Reproduce: 1. On a host with an HP Smart Array controller do something to cause a storage rescan, e.g. maybe put a host in maintenance mode. 2. Check '/var/log/messages' for "has a LUN larger than allowed by the host adapter" messages. Actual results: "has a LUN larger than allowed by the host adapter" messages reported on hosts with an HP Smart Array controller. Expected results: "has a LUN larger than allowed by the host adapter" messages reported not reported. Additional info:
Gordon, seems that we don't have any bug here for vdsm. If we already have bug for the relevant component, I think we should close this.
Nir, I've justed tested this here with 'vdsm-4.14.13-2' on a RHEV host with an HP Smart Array and no "has a LUN larger than allowed by the host adapter" messages were reported. Just to make sure, I checked this by echoing "- - -" to the scan file for the Smart Array host and I did get the "has a LUN larger than allowed by the host adapter" messages. I believe the 'vdsm-4.14.13-2' version has the new FC scan code in it from 'https://bugzilla.redhat.com/show_bug.cgi?id=1123637', where it issues a LIP to FC hosts. I also issued an 'iscsiadm -m session -R' manually and it just wrote "- - -" to the one iscsi host's scan file. So, this does appear to no longer be an issue. Based on this, we can close the bug. Thanks for looking into this. As always, your help is greatly appreciated. Regards, GFW.