Bug 667621

Created attachment 472014 [details]
vdsm.log

Created attachment 472015 [details]
getDeviceList.log

Created attachment 472018 [details]
multipath-list.log

Created attachment 472019 [details]
ovirt.log

Dan, this looks like a duplicate of Ortal's bug.
Seems there is a permissions problem with running cat as sudo:

Thread-34::DEBUG::2011-01-06 08:16:50,979::misc::96::irs::'/usr/bin/sudo -n /bin/cat /sys/devices/pci0000:00/0000:00:06.0/0000:0c:00.0/0000:0d:01.1/host2/scsi_host:host2/proc_name' (cwd None)
Thread-34::WARNING::2011-01-06 08:16:51,014::misc::121::irs::FAILED: <err> = 'sudo: sorry, a password is required to run sudo\n'; <rc> = 1
Thread-34::ERROR::2011-01-06 08:16:51,015::misc::62::irs::Internal file read failure: ('/sys/devices/pci0000:00/0000:00:06.0/0000:0c:00.0/0000:0d:01.1/host2/scsi_host:host2/proc_name',)
Thread-34::ERROR::2011-01-06 08:16:51,016::misc::63::irs::Traceback (most recent call last):
  File "/usr/share/vdsm/storage/multipath.py", line 199, in pathinfo
  File "/usr/share/vdsm/storage/iscsi.py", line 511, in devIsiSCSI
  File "/usr/share/vdsm/storage/misc.py", line 218, in readfileSUDO
MiscFileReadException: Internal file read failure: ('/sys/devices/pci0000:00/0000:00:06.0/0000:0c:00.0/0000:0d:01.1/host2/scsi_host:host2/proc_name',)

Thread-34::WARNING::2011-01-06 08:16:51,016::multipath::222::irs::(pathinfo) bad path line ' \_ 2:0:0:5  sdd 8:48  [active][ready]' is ignored
Thread-34::DEBUG::2011-01-06 08:16:51,016::misc::96::irs::'/usr/bin/sudo -n /sbin/multipath -ll 360a9800050334c33424a573531436868' (cwd None)
Thread-34::DEBUG::2011-01-06 08:16:51,122::misc::119::irs::SUCCESS: <err> = ''; <rc> = 0
Thread-34::DEBUG::2011-01-06 08:16:51,123::misc::96::irs::'/usr/bin/sudo -n /bin/cat /sys/devices/pci0000:00/0000:00:06.0/0000:0c:00.0/0000:0d:01.1/host2/scsi_host:host2/proc_name' (cwd None)
Thread-34::WARNING::2011-01-06 08:16:51,158::misc::121::irs::FAILED: <err> = 'sudo: sorry, a password is required to run sudo\n'; <rc> = 1
Thread-34::ERROR::2011-01-06 08:16:51,159::misc::62::irs::Internal file read failure: ('/sys/devices/pci0000:00/0000:00:06.0/0000:0c:00.0/0000:0d:01.1/host2/scsi_host:host2/proc_name',)
Thread-34::ERROR::2011-01-06 08:16:51,160::misc::63::irs::Traceback (most recent call last):
  File "/usr/share/vdsm/storage/multipath.py", line 199, in pathinfo
  File "/usr/share/vdsm/storage/iscsi.py", line 511, in devIsiSCSI
  File "/usr/share/vdsm/storage/misc.py", line 218, in readfileSUDO
MiscFileReadException: Internal file read failure: ('/sys/devices/pci0000:00/0000:00:06.0/0000:0c:00.0/0000:0d:01.1/host2/scsi_host:host2/proc_name',)

Thread-34::WARNING::2011-01-06 08:16:51,160::multipath::222::irs::(pathinfo) bad path line ' \_ 2:0:0:10 sdi 8:128 [active][ready]' is ignored
Thread-34::DEBUG::2011-01-06 08:16:51,161::misc::96::irs::'/usr/bin/sudo -n /sbin/multipath -ll 360a9800050334c33424a573531494658' (cwd None)
Thread-34::DEBUG::2011-01-06 08:16:51,248::misc::119::irs::SUCCESS: <err> = ''; <rc> = 0
Thread-34::DEBUG::2011-01-06 08:16:51,249::misc::96::irs::'/usr/bin/sudo -n /bin/cat /sys/devices/pci0000:00/0000:00:06.0/0000:0c:00.0/0000:0d:01.1/host2/scsi_host:host2/proc_name' (cwd None)
Thread-34::WARNING::2011-01-06 08:16:51,285::misc::121::irs::FAILED: <err> = 'sudo: sorry, a password is required to run sudo\n'; <rc> = 1
Thread-34::ERROR::2011-01-06 08:16:51,286::misc::62::irs::Internal file read failure: ('/sys/devices/pci0000:00/0000:00:06.0/0000:0c:00.0/0000:0d:01.1/host2/scsi_host:host2/proc_name',)
Thread-34::ERROR::2011-01-06 08:16:51,287::misc::63::irs::Traceback (most recent call last):
  File "/usr/share/vdsm/storage/multipath.py", line 199, in pathinfo
  File "/usr/share/vdsm/storage/iscsi.py", line 511, in devIsiSCSI
  File "/usr/share/vdsm/storage/misc.py", line 218, in readfileSUDO
MiscFileReadException: Internal file read failure: ('/sys/devices/pci0000:00/0000:00:06.0/0000:0c:00.0/0000:0d:01.1/host2/scsi_host:host2/proc_name',)

Yes, this indeed may have caused https://bugzilla.redhat.com/show_bug.cgi?id=565416#c9 ("Ortal's bug").

Pengzhen, does the following patch help you?

diff --git a/vdsm/storage/iscsi.py b/vdsm/storage/iscsi.py
index 60f3934..b6b6f1a 100644
--- a/vdsm/storage/iscsi.py
+++ b/vdsm/storage/iscsi.py
@@ -544,9 +544,8 @@ def checkSession(host, port, iqn, tpgt, user=None, password=None):
 def devIsiSCSI(dev):
 
     isiSCSI = False
-    hostdir = os.path.realpath(os.path.join("/sys/block", dev,
-        "device/../../.."))
-    host = os.path.basename(hostdir)
+    hostdir = os.path.join("/sys/block", dev, "device/../../..")
+    host = os.path.basename(os.path.realpath(hostdir))
     iscsi_host = os.path.join(hostdir, constants.STRG_ISCSI_HOST + host)
     scsi_host = os.path.join(hostdir, constants.STRG_SCSI_HOST + host)
     proc_name = os.path.join(scsi_host, "proc_name")

Hi Dan,

I can see the LUN with your patch, and can add the lun in rhevm with type FC.

-----------------
vendorID = NETAPP 
capacity = 10714349568 
fwrev = 0000 
vgUUID =  
pathlist = [] 
pathstatus = [{'physdev': 'sdk', 'state': 'active', 'lun': '11'}] 
devtype = FCP 
pvUUID =  
serial = SNETAPP_LUN_P3L3BJW51FgP 
GUID = 360a9800050334c33424a573531466750 
productID = LUN 
-----------------

So both hw.iSCSI/FC LUNs are recognized to type FCP , right?


(In reply to comment #6)
> Yes, this indeed may have caused
> https://bugzilla.redhat.com/show_bug.cgi?id=565416#c9 ("Ortal's bug").
> 
> Pengzhen, does the following patch help you?
> 
> diff --git a/vdsm/storage/iscsi.py b/vdsm/storage/iscsi.py
> index 60f3934..b6b6f1a 100644
> --- a/vdsm/storage/iscsi.py
> +++ b/vdsm/storage/iscsi.py
> @@ -544,9 +544,8 @@ def checkSession(host, port, iqn, tpgt, user=None,
> password=None):
>  def devIsiSCSI(dev):
> 
>      isiSCSI = False
> -    hostdir = os.path.realpath(os.path.join("/sys/block", dev,
> -        "device/../../.."))
> -    host = os.path.basename(hostdir)
> +    hostdir = os.path.join("/sys/block", dev, "device/../../..")
> +    host = os.path.basename(os.path.realpath(hostdir))
>      iscsi_host = os.path.join(hostdir, constants.STRG_ISCSI_HOST + host)
>      scsi_host = os.path.join(hostdir, constants.STRG_SCSI_HOST + host)
>      proc_name = os.path.join(scsi_host, "proc_name")

(In reply to comment #7)

> 
> So both hw.iSCSI/FC LUNs are recognized to type FCP , right?
> 

Actually, this sounds a bit odd to me. Is it expected, Ayal? Is it possible that this LUN is accessible by iSCSI, too?

(In reply to comment #8)
> (In reply to comment #7)
> 
> > 
> > So both hw.iSCSI/FC LUNs are recognized to type FCP , right?
> > 
> 
> Actually, this sounds a bit odd to me. Is it expected, Ayal? Is it possible
> that this LUN is accessible by iSCSI, too?

This is the expected behavior.
It is not that the LUN is accessible via iSCSI too, it is accessible ONLY via iscsi in this case.  Issue is that the iSCSI connection is done entirely on HBA (hardware) so we recognize it as non SW iSCSI device.  All such devices currently fall under the misnomer "FCP"

(In reply to comment #7)
> Hi Dan,
> 
> I can see the LUN with your patch, and can add the lun in rhevm with type FC.
> 
> -----------------
> vendorID = NETAPP 
> capacity = 10714349568 
> fwrev = 0000 
> vgUUID =  
> pathlist = [] 
> pathstatus = [{'physdev': 'sdk', 'state': 'active', 'lun': '11'}] 
> devtype = FCP 
> pvUUID =  
> serial = SNETAPP_LUN_P3L3BJW51FgP 
> GUID = 360a9800050334c33424a573531466750 
> productID = LUN 
> -----------------
> 
> So both hw.iSCSI/FC LUNs are recognized to type FCP , right?
Correct

this is fixed by
http://git.engineering.redhat.com/?p=users/dkenigsb/vdsm.git;a=commitdiff;h=89ff1dfb46834d015771622fbf0cb2a5a28db1c3

patches committed to RHEL-5 branch, moving to MODIFIED.

Closing all rhel-5.7 clones of rhev-2.2.6 bugs as they have served their purpose.