Bug 1011708

Summary: cannot mount iscsi partition after relogin
Product: [Fedora] Fedora Reporter: Frank Ansari <mail>
Component: iscsi-initiator-utilsAssignee: Chris Leech <cleech>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 19CC: agrover, cleech, hdegoede
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-24 23:34:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
iscsid.conf none

Description Frank Ansari 2013-09-24 21:50:53 UTC
Description of problem:
mount of iscsi partition not possible after relogin

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

How reproducible:
use Netgear ReadyNAS 102 as target

Steps to Reproduce:
1. iscsiadm -m discovery -t sendtargets -p 192.168.xx.yy
2. iscsiadm -m node -l
3. mount /dev/mapper/vol01-part01 /media/part01
4. umount /media/part01
5. iscsiadm -m node -u
6. iscsiadm -m node -l
7. mount /dev/mapper/vol01-part01 /media/part01

Actual results:
mount: /dev/mapper/vol01-part01: can't read superblock

Expected results:
This should work (at least this is what I would expect).

Additional info:
The behaviour is independent whether I use chap login or not.
The correct mount behaviour works again after rebooting the machine.
"systemctl restart iscsid.service" does not help.

Comment 1 Frank Ansari 2013-09-24 21:54:12 UTC
Created attachment 802514 [details]
iscsid.conf

Comment 2 Chris Leech 2013-09-24 23:22:04 UTC
I don't think the problem here is with the iSCSI session, but with whatever device mapper use you have going on.  Are you using LVM on the iSCSI disk?  I'm not sure how LVM on hotplug storage is handled, setting it up as a multipath disk may be one option for dealing with the fact that iSCSI session IDs and the SCSI host number associated with it will change when you log out and back in.

Comment 3 Chris Leech 2013-09-24 23:34:39 UTC
You can fix the mapping by disabling the existing one over the old disk ID with vgchange, then the mapping over the "new" disk won't have a conflicting name and will work (either when it's added if you disable before loging in, or by activating it manually)

 vgchange -an vol01 part01
 vgchange -ay vol01 part01

Comment 4 Frank Ansari 2013-09-25 18:07:28 UTC
Cool. This is working.

vgchange -an vol01
vgchange -ay vol01

does it for all partitons at once.