Error codes/return values of iscsiadm commands
How can we know error status of iscsiadm commands like discovery,login,logout. I think,all of them directly returns corresponding success/failure messages. so mostly I can just fire the commands without checking any error codes after it? I will really appreciate any help. Thank you. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: Error codes/return values of iscsiadm commands
Thanks for replies.
Yes,I generally do it using $? for other linux commands,but somehow
not comfortable doing it here.
iscsiadm -m ... sucess 2failure
and if file is non-empty,print the contents accordingly is what I can
think of.
It might be very ugly way of doing it.
On Jul 14, 2:20 pm, Mike Christie micha...@cs.wisc.edu wrote:
On 07/14/2010 12:56 PM, Boaz Harrosh wrote:
On 07/14/2010 08:23 PM, Mike Christie wrote:
On 07/14/2010 10:49 AM, Boaz Harrosh wrote:
On 07/14/2010 05:52 PM, Mike Christie wrote:
On 07/14/2010 05:30 AM, HIMANSHU wrote:
How can we know error status of iscsiadm commands like
discovery,login,logout.
I think,all of them directly returns corresponding success/failure
messages.
so mostly I can just fire the commands without checking any error
codes after it?
If you run
iscsiadm -m node -l
iscsiadm should return a error code like other programs. If you wanted
to see it you could do
iscsiadm -m node -l
echo $?
Speaking of which. When I want to completely run from a script file
I currently have two ugly loops
after starting the iscsi service and before I can iscsiadm I must do:
start_iscsi_intiator()
{
if ! service $ISCSI status; then
service iscsi start ;
until cat /sys/class/iscsi_transport/tcp/handle 2/dev/null ;
do
sleep 1;
done
fi
}
Effectively wait for the /sys/class/iscsi_transport/tcp/handle file to
appear
And after login but before I can actually start banging on my scsi device
I need:
login_iscsi()
{
echo login into: $IP_ISCSI
$iscsiadm -m discovery -t sendtargets -p $IP_ISCSI --login;
until ls $DEV_ISCSI 2/dev/null; do sleep 1; done
}
Effectively wait for the device to appear. This one is particularly nasty
because it assumes that I know what $DEV_ISCSI will be.
Would we want to add a --wait-server and --wait switches to iscsiadm
--wait-server - will wait for the iscsi-kernel-modules and iscsid
server
to stabilize. (until some timeout)
Not sure. When service iscsi start is run, it will eventually load the
modules. The script does not return until modprobe has returned and
modprobe does not return until the kernel module module_init function
and those do not return until it has run the sysfs functions that create
the files you are waiting on. So are you saying that once module_init
has completed the files are not accessible right away?
OK, so I just got lucky here probably, since I'm doing a sleep 1;
so the first iteration fails then a 1 sec wait is good enough. I think
what happens is that the iscsid server is not yet ready for communication
with iscsiadm. I'll remove the wait and run with debug-on see what actually
fails.
Oh yeah, Hannes had thought he saw what you are seeing too. Different
sysfs files though. I thought they should be created/ready by the time
we return from the module_init functions. I might be wrong or there
might be a bug in the sysfs code? I did not hear back from Hannes.
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: Persistent connections across initiator reboot
Exactly Ulrich,there can be a better approach. I am now having iscsiadm version 2.0-870,but still I am having a problem in case of 2 targets having different NODE authentication. My scenario Suppose 2 targets (having different NODE AUTHENTICATION,assuming same DISCOVERY AUTHENTICATION) from same target machine(say 30.12) are logged in.I set up node.startup=automatic in both cases. My observation If I restart initiator machine,re-login can be possible in case of last logged in target only,not both of them. Steps performed 1. Discover machine using -o new -o delete-Enter Node credentials for 1st target from the list shown-Discovery again as iscsid.conf is now having node credentials of target1-login to target1-making node.startup=automatic 2. Discover machine using -o new -o delete-Enter different Node credentials for 2nd target from the list shown-Discovery using -o update as iscsid.conf is now having node credentials of target2-login to target2-making node.startup=automatic (using -o update overwrites my node.startup setting of target1,so I have to again make node.startup of target1 to automatic.without -o update,it wont allow me to login as I need to change iscsid.conf to target2's credentials.) My conclusion Basically all this problem might be because of single iscsid.conf file.It should be different for every logged in target.Then only I can have all previous credentials stored. On Apr 30, 12:31 pm, Ulrich Windl ulrich.wi...@rz.uni- regensburg.de wrote: On 29 Apr 2009 at 11:25, Mike Christie wrote: Ulrich Windl wrote: On 28 Apr 2009 at 7:10, HIMANSHU wrote: One more question analogues to this. Suppose I login to 1st target from machine 30.12,it was having node authentication.so I saved its credentials in iscsid.conf and then I fired the discovery command followed by login command.It was successful and those credentials also got stored in nodes and send_targets. Then if I want to login to 2nd target which is also having node authentication from same machine,I am overwriting same iscsid.conf file.So I am loosing my previous credentials from iscsid.conf.Also after discovery,I am loosing previous target information from nodes and send_targets. Hi, I'm no expert, but I think the credentials are stored per node/target in the iSCSI database (like /etc/iscsi/send_targets/* and /etc/iscsi/nodes/*/*). Yeah, that is correct. When you run the discovery command or manual addition command, iscsiadm will read iscsid.conf and use those for the initial defaults for what gets created in those dirs. You can then change what is in those dirs using iscsiadm -m node -o update /etc/iscsi.conf just has the defaults. Probably it would be better to never touch the iscsid.conf, but provide auth information when discovering targets or loggin in to nodes/targets. However then the secrets would be on the command line (and process list, etc). I was thinking he has a issue where one target needs one set of CHAP values for the discovery session, then they need another set of CHAP values for another discovery session to another target. For this type of setup, you have to edit iscsid.conf, run iscsiadm -m discovery ..., then edit iscsid.conf again and then run iscsiadm -m discovery ... to the other target. Hi, That sounds like a workaround for some design deficit. Why not have a more flexible approach like ~/.netrc (a file that stores authentication information for several systems, keeping secrets away from the command line and the process list). I mean an option for discovery like --credentials-file=~/iscsi-credentials-for- You get the idea? Regards, Ulrich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Persistent connections across initiator reboot
One more question analogues to this. Suppose I login to 1st target from machine 30.12,it was having node authentication.so I saved its credentials in iscsid.conf and then I fired the discovery command followed by login command.It was successful and those credentials also got stored in nodes and send_targets. Then if I want to login to 2nd target which is also having node authentication from same machine,I am overwriting same iscsid.conf file.So I am loosing my previous credentials from iscsid.conf.Also after discovery,I am loosing previous target information from nodes and send_targets. So solution would be maintaining separate iscsid.conf files per logged in target.Can I do that here? ietd allows to read from different configuration file.right? On Apr 28, 9:19 am, HIMANSHU makhu...@yahoo.co.in wrote: Thank you very much Mike for all this. Can you please give me the test src rpm for CentOS 5.4? On Apr 27, 8:50 pm, Mike Christie micha...@cs.wisc.edu wrote: HIMANSHU wrote: I am now having 'iscsi-initiator-utils-6.2.0.868-0.18.el5' and performed the steps mentioned in my last post. Still after when I discover using 'iscsiadm -m discovery -t sendtargets -p 192.168.30.12 -o new -o delete',nodes and sendtargets entries gets overwritten. Sorry, sorry, my fault. I was looking up the current devel version. In RHEL 5.3/CentO35.3 and below there is no fix. You have to use the upstream code. I can also give you a test src rpm I am working on for RHEL 5.4/CentOs 5.4 if you want? It has the change needed. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Persistent connections across initiator reboot
Thank you very much Mike for all this. Can you please give me the test src rpm for CentOS 5.4? On Apr 27, 8:50 pm, Mike Christie micha...@cs.wisc.edu wrote: HIMANSHU wrote: I am now having 'iscsi-initiator-utils-6.2.0.868-0.18.el5' and performed the steps mentioned in my last post. Still after when I discover using 'iscsiadm -m discovery -t sendtargets -p 192.168.30.12 -o new -o delete',nodes and sendtargets entries gets overwritten. Sorry, sorry, my fault. I was looking up the current devel version. In RHEL 5.3/CentO35.3 and below there is no fix. You have to use the upstream code. I can also give you a test src rpm I am working on for RHEL 5.4/CentOs 5.4 if you want? It has the change needed. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Persistent connections across initiator reboot
I am now having 'iscsi-initiator-utils-6.2.0.868-0.18.el5' and performed the steps mentioned in my last post. Still after when I discover using 'iscsiadm -m discovery -t sendtargets -p 192.168.30.12 -o new -o delete',nodes and sendtargets entries gets overwritten. I am also not performing any target configuration changes on the target side in this whole process.Just discovery followed by 'node.startup update to automatic command'.and again performing discovery causes overwriting. Am I going wrong somewhere in the steps? Thanks and Regards, Himanshu Padmanabhi. On Apr 22, 6:38 pm, Mike Christie micha...@cs.wisc.edu wrote: HIMANSHU wrote: Thank you really.But I have not got the expected results. Steps 1. iscsiadm -m discovery -t sendtargets -p 192.168.30.12 -o new -o delete 2. iscsiadm -m node -T iqn.2009-04.com.systems:Target1 -p 192.168.30.12:3260 -o update -n node.startup -v automatic so '/var/lib/iscsi/nodes/iqn.2009-04.com.systems \:Target1/192.168.30.12\,3260\,1/default' entry changed from node.startup=manual(as specified in iscsid.conf) to node.startup=automatic 3. iscsiadm -m node -T iqn.2009-04.com.systems:Target1 -p 192.168.30.12:3260 --login 4. Then if I again perform step 1(i.e. discovery),node.startup gets overwritten as 'manual'. I have specified 'node.startup' entry to be 'manual' and will update it to 'automatic' only of those targets which are logged in. What is going wrong.Am I performing the same operations as you told? I am using iscsi-initiator-utils-6.2.0.868-0.7.el5 and it seems to have discovery switches. Do I need to upgrade it? Yeah, just upgrade to: iscsi-initiator-utils-6.2.0.868-0.18.el5 On Apr 21, 7:24 pm, Mike Christie micha...@cs.wisc.edu wrote: HIMANSHU wrote: Yeah.This worked for me.I specified 'node.startup=manual' in 'iscsid.conf'. so running update command to change it to 'automatic' only on login(or I will give option for persistent connection across reboot). But my problem these changes vanish after another discovery command. I login to one target say TAR1, from 30.51 and fired update command to change 'node.startup' to 'automatic'. and then after some time,If I want to login to another target from 30.51,I need to fire discovery command,which will make 'node.startup' of TAR1 changed to 'manual' again due to 'iscsid.conf'. You can pass the discovery commands some flags to indicated how you want it to manage the db. iscsiadm -m discovery -t st -p ip -o new will just add new target portals that are not in the db. iscsiadm -m discovery -t st -p ip -o delete will delete target portals that are in the db but no longer returned by the target in sendtargets discvoery. iscsiadm -m discovery -t st -p ip -o update was supposed to update target portal records that are in the db and returned by sendtargets using the iscsid.conf info. I checked the code today and it actually updates existing records and will add new ones using the iscsid.conf info. Then you can pass in combos. I think you want iscsiadm -m discovery -t st -p ip -o new -o delete this will add new records for new target portals, and delete records for targets no longer returned by the target, and for existing portals it will not update the records so your existing record settings will not be overwritten. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Persistent connections across initiator reboot
Is there any method or should I debug to know the exact cause of this overwriting problem? On Apr 24, 6:29 pm, HIMANSHU makhu...@yahoo.co.in wrote: I am now having 'iscsi-initiator-utils-6.2.0.868-0.18.el5' and performed the steps mentioned in my last post. Still after when I discover using 'iscsiadm -m discovery -t sendtargets -p 192.168.30.12 -o new -o delete',nodes and sendtargets entries gets overwritten. I am also not performing any target configuration changes on the target side in this whole process.Just discovery followed by 'node.startup update to automatic command'.and again performing discovery causes overwriting. Am I going wrong somewhere in the steps? Thanks and Regards, Himanshu Padmanabhi. On Apr 22, 6:38 pm, Mike Christie micha...@cs.wisc.edu wrote: HIMANSHU wrote: Thank you really.But I have not got the expected results. Steps 1. iscsiadm -m discovery -t sendtargets -p 192.168.30.12 -o new -o delete 2. iscsiadm -m node -T iqn.2009-04.com.systems:Target1 -p 192.168.30.12:3260 -o update -n node.startup -v automatic so '/var/lib/iscsi/nodes/iqn.2009-04.com.systems \:Target1/192.168.30.12\,3260\,1/default' entry changed from node.startup=manual(as specified in iscsid.conf) to node.startup=automatic 3. iscsiadm -m node -T iqn.2009-04.com.systems:Target1 -p 192.168.30.12:3260 --login 4. Then if I again perform step 1(i.e. discovery),node.startup gets overwritten as 'manual'. I have specified 'node.startup' entry to be 'manual' and will update it to 'automatic' only of those targets which are logged in. What is going wrong.Am I performing the same operations as you told? I am using iscsi-initiator-utils-6.2.0.868-0.7.el5 and it seems to have discovery switches. Do I need to upgrade it? Yeah, just upgrade to: iscsi-initiator-utils-6.2.0.868-0.18.el5 On Apr 21, 7:24 pm, Mike Christie micha...@cs.wisc.edu wrote: HIMANSHU wrote: Yeah.This worked for me.I specified 'node.startup=manual' in 'iscsid.conf'. so running update command to change it to 'automatic' only on login(or I will give option for persistent connection across reboot). But my problem these changes vanish after another discovery command. I login to one target say TAR1, from 30.51 and fired update command to change 'node.startup' to 'automatic'. and then after some time,If I want to login to another target from 30.51,I need to fire discovery command,which will make 'node.startup' of TAR1 changed to 'manual' again due to 'iscsid.conf'. You can pass the discovery commands some flags to indicated how you want it to manage the db. iscsiadm -m discovery -t st -p ip -o new will just add new target portals that are not in the db. iscsiadm -m discovery -t st -p ip -o delete will delete target portals that are in the db but no longer returned by the target in sendtargets discvoery. iscsiadm -m discovery -t st -p ip -o update was supposed to update target portal records that are in the db and returned by sendtargets using the iscsid.conf info. I checked the code today and it actually updates existing records and will add new ones using the iscsid.conf info. Then you can pass in combos. I think you want iscsiadm -m discovery -t st -p ip -o new -o delete this will add new records for new target portals, and delete records for targets no longer returned by the target, and for existing portals it will not update the records so your existing record settings will not be overwritten. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Persistent connections across initiator reboot
Thank you very much all.Problem is solved,but I am having doubt. @Mike On Apr 21, 5:08 am, Mike Christie micha...@cs.wisc.edu wrote: HIMANSHU wrote: I discovered 2 machine,192.168.7.50(containing 10 targets,out of which performed login on 2) and 192.168.7.51(containing 5 targets,out of which performed login on 3).I am using IET target and 'iscsi-initiator- utils-6.2.0.868-0.7.el5' initiator. So at present there are 5 connections on initiator.suddenly if initiator reboots. we are having following code in 'iscsi' service iscsiadm -m node --logoutall=all(stop function) iscsiadm -m node --loginall=automatic(start function) But disadvantage is that it will login to all 15 targets from both 7.50 and 7.51 machines,and not 5 which already were there.This is Do you have only the target records you want to log into automatically marked as node.startup=automatic? Yes,I am having all the targets marked as node.startup=automatic. because previous discovery entry is still there in /var/lib/iscsi/ nodes and /var/lib/iscsi/send_targets. I didn't follow you when you meantioned the previous entry. Are you running the iscsiadm discovery command at some point during startup? No,I am not running 'iscsiadm discovery' command at startup. If I commented above 2 lines from 'iscsi' service,It works fine for stop,start,restart service operations.i.e.initiator is restoring only connections which were there previously. are you running a custom script that logs into specific targets or how do you log into targets if the init script does not run loginall=automatic? User will specify IP addr for discovering targets.discovery command followed by login command for particular target selected by user.so I will fire 'iscsiadm update command to set node.startup as automatic' for this But this doesn't work across reboot.I lost my 5 connections after reboot though above 2 lines were commented. Thus,what should I do for persistent connections across reboot? I think you just want to set the targets you want to log into with the node.startup = automatic. When that loginall=automatic gets run, it will only log into those targets. Yeah.This worked for me.I specified 'node.startup=manual' in 'iscsid.conf'. so running update command to change it to 'automatic' only on login(or I will give option for persistent connection across reboot). But my problem these changes vanish after another discovery command. I login to one target say TAR1, from 30.51 and fired update command to change 'node.startup' to 'automatic'. and then after some time,If I want to login to another target from 30.51,I need to fire discovery command,which will make 'node.startup' of TAR1 changed to 'manual' again due to 'iscsid.conf'. So what can be the solution for this? How can I stop discovery command overwriting previous configuration? or I need to again fire 'update command'(for all those logged on that IP) after repeated discovery command? iscsiadm -m node -T target -p ip:port -o update -n node.startup -v startup I think with IET you can set up lists to control how can log into which target. Does that work for you? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Persistent connections across initiator reboot
I discovered 2 machine,192.168.7.50(containing 10 targets,out of which performed login on 2) and 192.168.7.51(containing 5 targets,out of which performed login on 3).I am using IET target and 'iscsi-initiator- utils-6.2.0.868-0.7.el5' initiator. So at present there are 5 connections on initiator.suddenly if initiator reboots. we are having following code in 'iscsi' service iscsiadm -m node --logoutall=all(stop function) iscsiadm -m node --loginall=automatic(start function) But disadvantage is that it will login to all 15 targets from both 7.50 and 7.51 machines,and not 5 which already were there.This is because previous discovery entry is still there in /var/lib/iscsi/ nodes and /var/lib/iscsi/send_targets. If I commented above 2 lines from 'iscsi' service,It works fine for stop,start,restart service operations.i.e.initiator is restoring only connections which were there previously. But this doesn't work across reboot.I lost my 5 connections after reboot though above 2 lines were commented. Thus,what should I do for persistent connections across reboot? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Nodes and Sendtargets directories use after login?
This is related to my this post. http://groups.google.com/group/open-iscsi/browse_thread/thread/40166b414bbda322/66ff12bbb I want to confirm my observations.If I am wrong,forgive me. Can I delete nodes and sendtargets once the discovery and login are done with 'target' from 'targetmachine1'? I am asking this for 'loginall' option. Suppose I want to login to all targets from ip say 192.168.30.56.Once discovery and login is done with previous machine 192.168.30.52,I wish to delete entries from nodes and sendtargets.then I will discover 192.168.30.56 where I may select 'loginall' option.At this time if I kept 30.52's entries still here,targets from it also get logged in which is not desired. Means after login to targets from 30.52,are these entries required at any instance?Then I cannot delete them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Is machine name allowed for login?
Thank you very much all. [r...@product_72 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.7.63 192.168.7.63:3260,1 iqn.2009-01.com.domain:t1 192.168.7.63:3260,1 iqn.2009-01.com.domain:t2 192.168.7.63:3260,1 iqn.2009-01.com.domain:t3 [r...@product_72 ~]# iscsiadm -m discovery -t sendtargets -p machine_63.domain.com 192.168.7.63:3260,1 iqn.2009-01.com.domain:t1 192.168.7.63:3260,1 iqn.2009-01.com.domain:t2 192.168.7.63:3260,1 iqn.2009-01.com.domain:t3 Yeah,I am getting ip while discovering through machine name also.So now disallowing discovery also using machine name.As mentioned,it is not there in the latest open-iscsi version either. In case of multiple interfaces for multiple ip's,corresponding entry should be there in dnsserver(concerning corresponding initiator and targets).Currently trying on single NIC. On Jan 16, 11:06 am, Nikhil Talpallikar nikhil.talpalli...@gmail.com wrote: AFAIK, This might be because u might have multiple interfaces up with different ip address. Now a target can provide for a login event only via the specified ip:port as the target is mapped to that interface. On Thu, Jan 15, 2009 at 10:26 PM, Mike Christie micha...@cs.wisc.eduwrote: HIMANSHU wrote: Hi all, I am asking very basic,simple question here.I am using iscsi- initiator-utils-6.2.0.865-0.2.fc7. iscsiadm -m discovery -t sendtargets -p ip:port It says that ip:port should be specified.It worked with 'machine name' stead of 'ip' also. This works in discovery, but iscsiadm -m node -T targetname -p ip:port --login But login command didn't work with replacing 'ip' by 'machine name'. does not work here because it is not implemented yet. You have to actually pass the login command whatever the target gave us in sendtargets discovery. So if it gave us a machine name you can use it. If it gave us a ip then you have to use it. Do not ask when it will be fixed. It is on the TODO, but I do not have much time right now. What should I do? is it way to login by 'machine name'.otherwise I will have to disallow discovery using 'machine name'. -- If you fool me once shame on you. If you fool me twice shame on me. \|||/ (o o) ooO-(_)-Ooo Nikhil Talpallikar --talli ;) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Is machine name allowed for login?
Hi all, I am asking very basic,simple question here.I am using iscsi- initiator-utils-6.2.0.865-0.2.fc7. iscsiadm -m discovery -t sendtargets -p ip:port It says that ip:port should be specified.It worked with 'machine name' stead of 'ip' also. iscsiadm -m node -T targetname -p ip:port --login But login command didn't work with replacing 'ip' by 'machine name'. What should I do? is it way to login by 'machine name'.otherwise I will have to disallow discovery using 'machine name'. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Data loss on network/service failure
IET target is connected by MS initiator.Data transfer is going on on the connected disk on initiator. TCP connection failed(because of any reason,service failure,problems in kernel modules) at say 't1' second.Initiator kept trying for reconnect. Initiator actually recognizes that target is down at say 't2' seconds. Then for the time between 't1' and 't2',data is written on the cache on initiator side giving illusion of data transfer.After some time,it gave delayed write error. So data is not actually stored on the target. What can we do here?Using high capacity network can be the solution in case of dedicated framework so that initiator will recognize the failure as early as possible. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Got my all data from remote disk even if I replaced the disk with other
Hi all, This is the surprising scenario. I created a VG containing one local and one remote(iSCSI) disk taken from target.Then I created 2-3 LV's with file system on it and filled them all with some data till they become full.Then I removed remote disk i.e. perform logout operation of iSCSI disk. So this VG became inconsistent.I can see that using pvscan where I will see unknown device in front of this VG Name. Then I replaced the remote disk with any other disk using pvcreate as follows. pvcreate --uuid UnknownDeviceID --restorefile /etc/lvm/backup/ VGNAME New disk and to my surprize,I found that I got all my data which is even on the remote disk.How is this possible? I am not having any RAID configurations here.I am having whole disk as a PV,not the partitions and LV's on that Physical volumes are created in a way that they are having their major parts on remote disk(In my case,2GB data was there on remote disk). How full data is derived from the metadata here? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Bi-Directional Authentication issues
I am sure I mailed to the right list..:) On Aug 29, 5:16 pm, HIMANSHU [EMAIL PROTECTED] wrote: I am using iscsi-initiator-utils-6.2.0.865-0.2.fc7 and iscsitarget-0.4.15-1 on CentOS5. CHAP says it adds Bidirectional authentication just to add a second level of security in which initiator authenticates the target. Even though target specified Bi-Directional Credentials,Initiator can login even by specifying Incoming credentials.Wrong Outgoing credentials are not allowed.But blank are allowed. Is it specified by CHAP?or it should not be like that?Please help. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Bi-Directional Authentication issues
I am using iscsi-initiator-utils-6.2.0.865-0.2.fc7 and iscsitarget-0.4.15-1 on CentOS5. CHAP says it adds Bidirectional authentication just to add a second level of security in which initiator authenticates the target. Even though target specified Bi-Directional Credentials,Initiator can login even by specifying Incoming credentials.Wrong Outgoing credentials are not allowed.But blank are allowed. Is it specified by CHAP?or it should not be like that?Please help. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: open-iscsi installation
Hello, You need iscsi-initiator-utils-6.2.0.version for using iscsiadm commands. On Jul 17, 1:38 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I am trying to install open-iscsi package in the suse linux. But I am facing some problem while installation. When we complete this installation do we need to add separate package for iscsiadm command? Coz I unable to use this iscsiadm command after completing this installation and I could not find the script for iscsiadm command in / etc/init.d as well. How can I make my server prepared to use the commands like iscsiadm, iscsi-iname, iscsi-ls, Please somebody help me. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: IMPORTANT....initiator sensing target daemon restart + Header and Data Digest
Let me take this a chunk at a time :) HIMANSHU wrote: My previous problem that initiator cannot recover the connection after target daemon restart/target machine reboot was solved. It was a really a silly mistake. Initiator side Header,Data digest configuration was not set according to target side. I set both to None.Then it can recover the connection.Though target side settings can be anything out of the 4 options.But it is not still working correctly with CRC32C instead of None. What is actually the need of Header and Data Digest??? Are you changing the digest values between target restarts/reboots? No,I m not changing them.Is that expected during restart/reboot? Have u checked my mail? On Jul 3, 7:20 am, Mike Christie [EMAIL PROTECTED] wrote: Does it have something to do with Discovery/Node level authentication?? Or it just checks Header/Data integrity using checksum on both sides to ensure packets are not tampered. Digests are used to ensure packets are the same as what was sent. I am using version 865.Version 868 doesn't make use of Data Digest at all. What do you mean by 868 not making use of data digests? In version 868,in iscsid.conf,DataDigest parameter is not specified like version 865. you are probably taking some default value. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
IMPORTANT....initiator sensing target daemon restart + Header and Data Digest
Hello, First of all,Thanks Mike for your continuous help. You are really making this list active. --- Consider the scenario, Open-iSCSI initiator connected to one IET target from target machine. Presently 2 LUN's were attached to it. Target machine adds 3rd LUN to the same target which is exposed to increase storage. Target machine daemon(iscsi-target) is restarted to make the changes reflect the initiator side. Initiator may/may not be undergoing I/O on the 2 exposed LUN's at that instance. on firing iscsiadm -m session -P 3,it will show status as Blocked for 1-2 seconds indicating that target configuration is changed. Then initiator has to perform iscsiadm -m session --rescan to add the 3rd LUN to target already exposed. My question is, 1. Which signal initiator receives from target so that it can know target daemon is restarted?? I want initiator to have access of 3rd LUN after target added it.i.e. on which event,I should run iscsiadm -m session --rescan?? 2. One way could be on initiator side,I should write a daemon/program to run iscsiadm -m session -P 3 continuously to sense if Disk state is blocked and iSCSI state is REOPEN.At that instance, I can run iscsiadm -m session --rescan to make changes reflect. But it will unnecessarily overload CPU a bit. My previous problem that initiator cannot recover the connection after target daemon restart/target machine reboot was solved. It was a really a silly mistake. Initiator side Header,Data digest configuration was not set according to target side. I set both to None.Then it can recover the connection.Though target side settings can be anything out of the 4 options.But it is not still working correctly with CRC32C instead of None. What is actually the need of Header and Data Digest??? Does it have something to do with Discovery/Node level authentication?? Or it just checks Header/Data integrity using checksum on both sides to ensure packets are not tampered. I am using version 865.Version 868 doesn't make use of Data Digest at all. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: IMPORTANT....initiator sensing target daemon restart + Header and Data Digest
Detailed results are mailed to you mike.It is an excel table.I couldn't paste it here. Vaguely,We could conclude that if CRC32C was there @ iscsid.conf,it was unable to recover the connection.Disks show blocked for many time after which they become running but iSCSI connection state remains REOPEN making disks inaccessible. Is that if authentication given on target side(uni/bi) then use CRC32C in iscsid.conf If no authentication,then use None in iscsid.conf CRC32C,None and None,CRC32C options behaviour looks similar. Which one we should go for out of these 4 and when are these used? - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Wthreads issue
# ietadm --op show --tid=1 Wthreads=8 Type=0 QueuedCommands=32 On Jun 28, 5:46 pm, HIMANSHU [EMAIL PROTECTED] wrote: I am having Wthreads 8 in my IET /etc/ietd.conf So after restarting target module and daemon,Initiator failed to connect to it due to absense of Wthreads. How to specify Wthreads 8 in /etc/iscsi/iscsid.conf? node.session.iscsi.Wthreads = 8OR node.conn[0].iscsi.Wthreads = 8OR It is not supported by Open-iSCSI. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Problems of discovery @ 868.0.7
Hi I switched to iscsi-initiator-utils-6.2.0.868-0.7.fc9 from iscsi- initiator-utils-6.2.0.865-0.2.fc7. Facing problem at discovery. # iscsiadm -d 8 --mode discovery --type sendtargets --portal 192.168.7.174:3260 iscsiadm: ip 192.168.7.174, port 3260, tgpt -1 iscsiadm: Max file limits 1024 1024 iscsiadm: can not connect to iSCSI daemon (111)! iscsiadm: Could not get config file for sync config iscsiadm: starting sendtargets discovery, address 192.168.7.174:3260, iscsiadm: can not connect to iSCSI daemon (111)! iscsiadm: Cannot perform discovery. Initiatorname required. iscsiadm: Discovery process to 192.168.7.174:3260 failed to create a discovery session. # cat /etc/iscsi/initiatorname.iscsi InitiatorName=iqn.2005-03.org.open-iscsi:5a3ea76f6c20 What went wrong? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Fileio Vs. Blockio
If lun is having LV(i.e.Virtual Block device) in it,then it should be exposed as Blockio. If it is exposing Regular file,then it should use Fileio. Is it right? Regular file is exposed as a disk.What is difference between 'Blockio and Fileio in iSCSI. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: dynamic behaviour of device name
Hi Vaibhav, I am facing similar problem after restart that Disks on the initiator side becomes inaccessible. Which service are you restarting? iscsi-target service? Did you modified it? Probably on sensing iscsi-target restart on initiator side,you might be relogging to it. At that time,it might take a different disk if earlier device name busy somewhere. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
iSCSI + LVM issues
Hello... 1. Initiator is using one disk,Creates VG,LV on it.automounts LV. But these VG,LV become visible(accessible) on the target side also... This is not desirable feature.Right?...Any solution?? M using IET 16.1 and open-iscsi(865-0.2).. 2. Initiator is using one disk,Creates VG,LV on it.automounts LV. Writes some data on it... It logouts that diskAgain logins to same disk.. Data written previously becomes Read Only. Seems like LVM couldn't understand login-logout funda's and got crashed.. getting this error after vgs. /dev/sdh: read failed after 0 of 4096 at 0: Input/output error /dev/sdj: read failed after 0 of 4096 at 0: Input/output error 2nd time login should allow me to access the data written at 1st time on the LV's. If i manually create partition,file system and mount it somewhere,then Data is accessible at the later logins...This is desirable. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Few iSCSI questions
1. You say that performance figures are this.. single iSCSI session: * 450MB/s Read and 450 MB/s Write for 64KB block * 510 MB/s Read and 550 MB/s Write for 256KB block * 65,000 IOPS - 1K, 58,000 IOPS - 2K, 50,000 IOPS with 4KB Read two iSCSI sessions: * 550 MB/s Read and 810 MB/s Write for 256KB block * 75,000 IOPS for 1K block How can we measure figures on our machine? Iometer , disktest are few tools available for that. Can u suggest any good one? --- 2. When Initiator can get access to disk from target,What all applications user can have?Means besides Storage,what is the use of this Disk? 3. If one initiator is logged in to target iqn. 2008-06.com.companyname:BLOCKIO_TARGET which is 1 GB. It thus have access to it,it partitions it using fdisk.Creates file system using mkfs.mounts it and writes 300 MB data on it. If second initiator machine logs in to the same target,it can view all the 300 MB data written by 1st initiator if 2nd initiator doesn't format that disk after login. 2nd initiator only mounts the logged in disk and thus had access to all the 300 MB data. Is it ethical? Should we allow same target to be shared by multiple initiators at the same time? What will be the pros and cons? I think,we need to handle synchronization issues there.Data written by 1st initiator shouldn't be deleted by others and all.. Or Data from 1st initiator should not be visible/accessible to others. What approach looks more ethical and practical? --- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Syntax for logging in to regular file
Currently iSCSI targets contains LV's. -- Target iqn.2008-06.com.qualexsystems:Tar3 Alias Tar3 #instead of adding LV here,regular file should be added. Lun 0 Path=/dev/Vg1/lvISCSI3,Type=fileio HeaderDigest CRC32C,None InitialR2T Yes MaxBurstLength 262144 MaxRecvDataSegmentLength 8192 DataPDUInOrder Yes ImmediateData No MaxXmitDataSegmentLength 8192 FirstBurstLength 65536 MaxOutstandingR2T 8 DataSequenceInOrder Yes DataDigest CRC32C,None DefaultTime2Wait 2 MaxConnections 1 DefaultTime2Retain 20 ErrorRecoveryLevel 0 Wthreads 8 - Do u know how it can be achieved?i.e.Basically how to export regular files from target? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Data becomes ReadOnly on logout
Suppose Initiator is logged in to a Disk,It created File System on it.Then after mounting,written some data in it. After this,Initiator logged out that target.If it Again logged in to same target,all previously written data was accessible. This is normal and expected behavior.I want same behavior in the above case. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Syntax for logging in to regular file
Hi, 1.To discover targets, iscsiadm --mode discovery --type sendtargets --portal 'target_ip' 2.For login, iscsiadm -m node -T 'target_name' -p 'target_ip':3260 --login 3. Use exported disk on initiator(create PV,LV,use that LV etc.) 4. For logout, iscsiadm -m node -T 'target_name' -p 'target_ip':3260 --logout All above is for Virtual block devices(RAID/LVM). What are the similar commands if i want to discover,login,logout regular files? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Should connection restored?
Thanks a lot Konrad and Mike for your continuous help. @Konrad Sorry, I meant to say If I/O going on,it shouldn't be allowed to logout that target. Suppose I added few targets and want initiators should know this change,i should restart iscsi-target daemon.Without this,iscsiadm - m discovery. cannot detect addition of these new targets..It still shows OLD ones. Does it mean according to you,addition of new target should be spread by target itself or discovery command should sense it?? How initiator can sense addition of new targets other than discovery? Are there any special commands?I am using IET. LUN addition can be sensed by --rescan.But after restarting iscsi- target,as disks status is blocked,--rescan command hangs up completely. so after restarting iscsi-target,New target/LUN's can be sensed,But original connections are lost. Is it normal behavior of IET? -- @Mike Yeah..I am using IET. I was getting session recovery timed out after 120 secs when it was 120. Now as it is 86400,I never observed after 86400sec. that session recovery timed out after 86400 secs. Otherwise is it NORMAL behavior of IET that the connection is lost of existing targets after restarting target daemon? In Open-e,it was the case that disk blocked only some time,after it was recovered. But in my case,it is blocked forever. Open-e might changed IET to suit this persistent connection or they might be using something else?Thoughts - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Should connection restored?
I changed timeout as follows. 1. iscsiadm --mode discovery --type sendtargets --portal 192.168.7.174 2. iscsiadm -m node -T iqn.2008-05.com.abcde:Tar1 -p 192.168.7.174:3260 --login 3. iscsiadm -m node -T iqn.2008-05.com.qualexsystems:Tar1 -p 192.168.7.174:3260 -o update -n node.session.timeo.replacement_timeout -v 82400 (got succedded) 4. I mounted disk exposed and started some i/o on it. 5. Then i restarted iscsi-target daemon output of dmesg after during step 4 - __journal_remove_journal_head: freeing b_frozen_data scsi 1:0:0:1: rejecting I/O to dead device Buffer I/O error on device sdh1, logical block 529 lost page write due to I/O error on sdh1 scsi2 : iSCSI Initiator over TCP/IP Vendor: IET Model: VIRTUAL-DISK Rev: 0 Type: Direct-Access ANSI SCSI revision: 04 SCSI device sdg: 630784 512-byte hdwr sectors (323 MB) sdg: Write Protect is off sdg: Mode Sense: 77 00 00 08 SCSI device sdg: drive cache: write through SCSI device sdg: 630784 512-byte hdwr sectors (323 MB) sdg: Write Protect is off sdg: Mode Sense: 77 00 00 08 SCSI device sdg: drive cache: write through sdg: sdg1 sd 2:0:0:0: Attached scsi disk sdg sd 2:0:0:0: Attached scsi generic sg6 type 0 Vendor: IET Model: VIRTUAL-DISK Rev: 0 Type: Direct-Access ANSI SCSI revision: 04 SCSI device sdh: 630784 512-byte hdwr sectors (323 MB) sdh: Write Protect is off sdh: Mode Sense: 77 00 00 08 SCSI device sdh: drive cache: write through SCSI device sdh: 630784 512-byte hdwr sectors (323 MB) sdh: Write Protect is off sdh: Mode Sense: 77 00 00 08 SCSI device sdh: drive cache: write through sdh: sdh1 sd 2:0:0:1: Attached scsi disk sdh sd 2:0:0:1: Attached scsi generic sg7 type 0 kjournald starting. Commit interval 5 seconds EXT3 FS on sdh1, internal journal EXT3-fs: mounted filesystem with ordered data mode. dmesg after step 5 session1: iscsi: session recovery timed out after 120 secs iscsi: cmd 0x2a is not queued (7) sd 2:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdh, sector 390208 Buffer I/O error on device sdh1, logical block 195073 lost page write due to I/O error on sdh1 Buffer I/O error on device sdh1, logical block 195074 lost page write due to I/O error on sdh1 Aborting journal on device sdh1. iscsi: cmd 0x2a is not queued (7) sd 2:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdh, sector 390208 Buffer I/O error on device sdh1, logical block 195073 lost page write due to I/O error on sdh1 Buffer I/O error on device sdh1, logical block 195074 lost page write due to I/O error on sdh1 __journal_remove_journal_head: freeing b_committed_data ext3_abort called. EXT3-fs error (device sdh1): ext3_journal_start_sb: Detected aborted journal Remounting filesystem read-only iscsi: cmd 0x2a is not queued (7) sd 2:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdh, sector 66 Buffer I/O error on device sdh1, logical block 2 lost page write due to I/O error on sdh1 iscsi: cmd 0x2a is not queued (7) iscsi: cmd 0x2a is not queued (7) sd 2:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdh, sector 376896 Buffer I/O error on device sdh1, logical block 188417 lost page write due to I/O error on sdh1 sd 2:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdh, sector 376900 Buffer I/O error on device sdh1, logical block 188419 lost page write due to I/O error on sdh1 --- What is exactly happening here? timeout value is changing from 120 to 86400..How can i re-confirm that? Can there be some other problem as well? - Target: iqn.2008-05.com.qualexsystems:Tar2 Current Portal: 192.168.7.174:3260,1 Persistent Portal: 192.168.7.174:3260,1 ** Interface: ** Iface Name: default Iface Transport: tcp Iface IPaddress: default Iface HWaddress: default Iface Netdev: default SID: 4 iSCSI Connection State: LOGGED IN Internal iscsid Session State: NO CHANGE Negotiated iSCSI params: HeaderDigest: CRC32C DataDigest: None MaxRecvDataSegmentLength: 131072 MaxXmitDataSegmentLength: 8192 FirstBurstLength: 65536 MaxBurstLength: 262144 ImmediateData: No InitialR2T: Yes MaxOutstandingR2T: 1
Re: Should connection restored?
I) How to increase replacement_timeout on initiator? echo 82400 /sys/block/sdh/device/timeout or After discovery,nodes sendtargets are created.In nodes,there is default file. node.session.timeo.replacement_timeout = 120 node.session.err_timeo.abort_timeout = 10 node.session.err_timeo.reset_timeout = 30 node.session.iscsi.FastAbort = Yes node.conn[0].timeo.logout_timeout = 15 node.conn[0].timeo.login_timeout = 15 node.conn[0].timeo.auth_timeout = 45 node.conn[0].timeo.active_timeout = 5 node.conn[0].timeo.idle_timeout = 60 node.conn[0].timeo.ping_timeout = 5 node.conn[0].timeo.noop_out_interval = 10 node.conn[0].timeo.noop_out_timeout = 15 ... ... Can these values be useful to me?Or only replacement timeout HIGH value and node.conn[0].timeo.noop_out_interval = 0 node.conn[0].timeo.noop_out_timeout = 0 as given in documentation will do? And 1 more replacement timeout is not available in target side? Right.Only to be changed on the initiator side. Here's target's ietd file Target iqn.2008-04.com.qualexsystems:Tar1 Alias Tar1 Lun 1 Path=/dev/Vg1/Lv2,Type=fileio Lun 0 Path=/dev/Vg1/Lv1,Type=fileio HeaderDigest CRC32C,None InitialR2T Yes MaxBurstLength 262144 MaxRecvDataSegmentLength 8192 DataPDUInOrder Yes ImmediateData No MaxXmitDataSegmentLength 8192 FirstBurstLength 65536 MaxOutstandingR2T 8 DataSequenceInOrder Yes DataDigest CRC32C,None DefaultTime2Wait 2 MaxConnections 1 DefaultTime2Retain 20 ErrorRecoveryLevel 0 Wthreads 8 - II) After particular target iqn.2008-04.com.qualexsystems:Tar1 is logged in to an initiator,is it Ethical to add LUN's on that target? -- III) If CHAP Bidirectional authentication is is given to 2 targets Tar1 Tar2,Can same initiator machine can login to both targets? Because for 2nd targets login,/etc/iscsi/iscsid.conf on the initiator should be changed so that login can be possible.But here we are losing our previous target's authentication,when we overwrite iscsid.conf with Tar2s Uname Pwd. And still Tar1 is logged in though iscsid.conf doesn't contain it's Authentication parameters,but contain Tar2's.Is it accepted behavior or it is weird?Your views -- IV) We are not using Multipath.So i can't try your previous suggestion. Spring for an extra nic on the target and use multipath and set queue_if_no_path or no_path_retry queue. -- Is there any other way to make connections persistent?When i used open-e(DSS) as target machine,Initiator retained persistent connections after target restart.Our target restart code is already mentioned earlier. Thank you very much - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Persistent connection problem
Hello All, 1. I am using latest iscsitarget-0.4.16-1 from sourceforge. Now,can you tell whether it is expected to retain the connection with initiator once the target is restarted? - 2. You wrote. The reason for having you do iscsid -d 8 was so we could see why we cannot log back in iscsid -d 8 log messages can be seen from dmesg...right? check 2nd last line here in dmesg.connection13:0: iscsi: detected conn error (1011) --- iscsi: cmd 0x28 is not queued (7) iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 8 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 835576 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 835576 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 iscsi: cmd 0x28 is not queued (7) iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 8 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 16 sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 scsi14 : iSCSI Initiator over TCP/IP - Hide quoted text - - Show quoted text - Vendor: IET Model: VIRTUAL-DISK Rev: 0 Type: Direct-Access ANSI SCSI revision: 04 SCSI device sdh: 1048576 512-byte hdwr sectors (537 MB) sdh: Write Protect is off sdh: Mode Sense: 77 00 00 08 SCSI device sdh: drive cache: write through SCSI device sdh: 1048576 512-byte hdwr sectors (537 MB) sdh: Write Protect is off sdh: Mode Sense: 77 00 00 08 SCSI device sdh: drive cache: write through sdh: sdh1 sd 14:0:0:0: Attached scsi disk sdh sd 14:0:0:0: Attached scsi generic sg6 type 0 Vendor: IET Model: VIRTUAL-DISK Rev: 0 Type: Direct-Access ANSI SCSI revision: 04 SCSI device sdi: 835584 512-byte hdwr sectors (428 MB) sdi: Write Protect is off sdi: Mode Sense: 77 00 00 08 SCSI device sdi: drive cache: write through SCSI device sdi: 835584 512-byte hdwr sectors (428 MB) sdi: Write Protect is off sdi: Mode Sense: 77 00 00 08 SCSI device sdi: drive cache: write through sdi: sdi1 sd 14:0:0:1: Attached scsi disk sdi sd 14:0:0:1: Attached scsi generic sg7 type 0 connection13:0: iscsi: detected conn error (1011) session13: iscsi: session recovery timed out after 120 secs --- 3. when session is recovered. [EMAIL PROTECTED] iscsi]# iscsiadm -m session -P 3 iSCSI Transport Class version 1.1-646 iscsiadm version 2.0-865 Target: iqn.2008-04.com.qualexsystems:Tar1 Current Portal: 192.168.7.173:3260,1 Persistent Portal: 192.168.7.173:3260,1 ** Interface: ** Iface Name: default Iface Transport: tcp Iface IPaddress: default Iface HWaddress: default Iface Netdev: default SID: 13 iSCSI Connection State: IN LOGIN Internal iscsid Session State: REPOEN Negotiated iSCSI params: HeaderDigest: None DataDigest: None MaxRecvDataSegmentLength: 8192 MaxXmitDataSegmentLength: 8192 FirstBurstLength: 65536 MaxBurstLength: 262144 ImmediateData: No InitialR2T: Yes MaxOutstandingR2T: 1 Attached SCSI devices: Host Number: 14 State: running scsi14 Channel 00 Id 0 Lun: 0 Attached scsi disk sdh State: running scsi14 Channel 00 Id 0 Lun: 1 Attached scsi disk sdi State: running Though Disk state is running,still iSCSI Connection State: IN LOGIN. So disks still becomes unusable.
