Re: Problem with auto-starup on Debian 6
What my final solution is to disable the rcS.d and just call it in rc.local after a sleep 5. This was the only way to be 100% sure that no errors were present at the log. If I didn't do any sleep, it worked but there was still an error first, and then 2 seconds later everything was ok. My VPS host told me that it's probably because the IPv6 address is received from network while the IPv4 address is manually specified. So it might take a few seconds to get the address. I guess the problem is either: 1. iscsi is testing for _any_ network connectivity, so when IPv4 is ready then it tries to connect even though the IPv6 isn't. A fix would be to test using the actual interface, not just using any network connectivity (might be hard to implement). 2. Or yes, an alternative fix might be to just increase the tryout number. 3. Or maybe what's happening is that since the interface doesn't exists it doesn't starts trying again, but terminates the whole process, since there was no interface at that time. I guess this was happening in my case. Also, there is a bug in the Debian package, `modprobe scsi_transport_iscsi` is missing, while the other 2 modprobes are present. It'll take some time for everyone trying to install iscsi to figure out that this modprobe is missing and you have to add it manually to /etc/modules. Also, making a change like this permanent in modules isn't really an elegant solution, so adding that line in the Deb 6 packages would be important. Are the maintainers present on this forum? Sending a bug report for Debian is such a hassle, I'd be happy if I could just reach them here. Regards, Zsolt On 8 January 2013 23:03, Mike Christie micha...@cs.wisc.edu wrote: On 01/08/2013 05:39 AM, zsolt@gmail.com wrote: I'm having problem configuring open-iscsi on Debian 6 to automatically start-up. I've configured everything and if I manually run *invoke-rc.d open-iscsi restart* then it runs fine! However after a simple reboot, nothing happens. This is the log in the daemon.log / syslog: Jan 8 11:31:51 ssdkvm iscsid: iSCSI logger with pid=1985 started! Jan 8 11:31:52 ssdkvm iscsid: transport class version 2.0-870. iscsid version 2.0-871 Jan 8 11:31:52 ssdkvm iscsid: iSCSI daemon with pid=1986 started! Jan 8 11:31:53 ssdkvm iscsid: connection1:0 is operational now . Jan 8 11:32:18 ssdkvm iscsid: transport class version 2.0-870. iscsid version 2.0-871 Jan 8 11:32:18 ssdkvm iscsid: iSCSI daemon with pid=929 started! *Jan 8 11:32:18 ssdkvm iscsid: cannot make a connection to 2a00:. (-1,101)* * * Why is this happening? Is the network not up when this line is present? Probably. It might be coming up. 101 is ENETUNREACH Network is unreachable, so the networking might be coming up while is also starting up. It might be that by the time you can log in and run commands, the network is up so your invoke call then works. Does Your iscsid.conf have the setting initial_login_retry_max? You can try increasing this. Make sure that you have disabled remove invalid portals that are not going to come up or we will wait on them, and also remember to run iscsiadm -o update to update the existing settings with the new value or rerun the discovery command. (possibly because of IPv6?) How can I fix it? Remove the line from rcS.d and append *invoke-rc.d open-iscsi start *to rc.local? Regards, Zsolt -- You received this message because you are subscribed to the Google Groups open-iscsi group. To view this discussion on the web visit https://groups.google.com/d/msg/open-iscsi/-/gMNaQs8I6lsJ. 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?hl=en. -- 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?hl=en.
Re: Initiator name missing
Hello again Mike / open-iscsi community, Any clue as to what might be missing for me? Is there a way to update by editing a file as opposed to typing in the commands? It seems so close to being figured out but I'm stumped! Thanks again Jeff On Fri, Jan 4, 2013 at 4:37 PM, Jeff Bye jeff...@gogoluckey.com wrote: 2.0-871 is what I'm running Jeff On Fri, Jan 4, 2013 at 4:17 PM, Jeff Bye jeff...@gogoluckey.com wrote: I tried all of the commands and none of them worked for me: *deadlineserver@deadlineserver ~ $ iscsiadm -m discoverydb -t st -p 10.10.0.1:3260 -o delete* iscsiadm -m discovery [ -hV ] [ -d debug_level ] [-P printlevel] [ -t type -p ip:port -I ifaceN ... [ -l ] ] | [ -p ip:port ] [ -o operation ] [ -n name ] [ -v value ] iscsiadm -m node [ -hV ] [ -d debug_level ] [ -P printlevel ] [ -L all,manual,automatic ] [ -U all,manual,automatic ] [ -S ] [ [ -T targetname -p ip:port -I ifaceN ] [ -l | -u | -R | -s] ] [ [ -o operation ] [ -n name ] [ -v value ] ] iscsiadm -m session [ -hV ] [ -d debug_level ] [ -P printlevel] [ -r sessionid | sysfsdir [ -R | -u | -s ] [ -o operation ] [ -n name ] [ -v value ] ] iscsiadm -m iface [ -hV ] [ -d debug_level ] [ -P printlevel ] [ -I ifacename ] [ [ -o operation ] [ -n name ] [ -v value ] ] iscsiadm -m fw [ -l ] iscsiadm -m host [ -P printlevel ] [ -H hostno ] iscsiadm -k priority *I checked man iscsiadm and found:* -m, --mode op specify the mode. op must be one of discovery, node, fw, host iface or session. If no other options are specified: for discovery and node, all of their respective records are displayed; for session, all active sessions and connections are displayed; for fw, all boot firmware values are displayed; for host, all iSCSI hosts are displayed; and for iface, all ifaces setup in /etc/iscsi/ifaces are displayed. Am I running the wrong version perhaps? Jeff On Thu, Jan 3, 2013 at 7:05 PM, Mike Christie micha...@cs.wisc.eduwrote: The iscsid.conf values are the defaults one used to setup the port/node/target db. If you clear the iscsid.conf values, you would still need to update the db ones for it to take effect on existing targets you have already setup. For the discovery values you can either delete the old discovery record: iscsiadm -m discoverydb -t st -p ip -o delete When you run the discovery command next, then it will use the iscsid.conf settings to create the discovery record. or if your tools does not support that command you can clear the chap settings iscsiadm -m discoverydb -t st -p ip -o update -n discovery.sendtargets.auth.username -v iscsiadm -m discoverydb -t st -p ip -o update -n discovery.sendtargets.auth.password -v iscsiadm -m discoverydb -t st -p ip -o update -n discovery.sendtargets.auth.authmethod -v none On 01/03/2013 01:46 PM, Jeff Bye wrote: Hey! I've been out of town for a couple of weeks. Hope you had a chance to take some time off as well :) It seems that the username and password I had initially set up is still being used, however in iscsid.conf CHAP is set to none and any other information has been commented. Does this only affect the target side? Jeff When I had it running on a windows machine (a temporary setup) we kept it open and On Fri, Dec 21, 2012 at 1:32 AM, Mike Christie micha...@cs.wisc.edu mailto:micha...@cs.wisc.edu wrote: On 12/20/2012 06:54 PM, GGL wrote: deadlineserver@deadlineserver / $ sudo iscsiadm -m discovery -t sendtargets -p 10.10.0.1 iscsiadm: Login authentication failed with target Yeah, this is a CHAP failure. Is it turned off on the target too? Could you run sudo iscsiadm -m discovery -t sendtargets -p 10.10.0.1 -d 8 and send all the output? Also while running this command run: tcpdump -w iscsi.discovery.out -i your_eth_device and then send that iscsi.discovery.out file. It will show us what the target is sending on the wire too. Both of those files will have passwords in them if you have CHAP settings still being used, so send me them in private or edit out the values if you do not want them on the open. -- Jeff Bye Graphics Coordinator Liberty Post 12910 Culver Blvd. Suite G Los Angeles, CA 90066 (310) 314-3900 x247 -- 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?hl=en. -- Jeff Bye Graphics Coordinator Liberty Post 12910 Culver Blvd. Suite G Los Angeles, CA 90066 (310) 314-3900 x247 -- Jeff Bye Graphics Coordinator Liberty Post 12910 Culver Blvd. Suite G
Re: Problem with auto-starup on Debian 6
On 01/09/2013 03:36 AM, Zsolt Ero wrote: What my final solution is to disable the rcS.d and just call it in rc.local after a sleep 5. This was the only way to be 100% sure that no errors were present at the log. If I didn't do any sleep, it worked but there was still an error first, and then 2 seconds later everything was ok. My VPS host told me that it's probably because the IPv6 address is received from network while the IPv4 address is manually specified. So it might take a few seconds to get the address. I guess the problem is either: 1. iscsi is testing for _any_ network connectivity, so when IPv4 is ready then it tries to connect even though the IPv6 isn't. A fix would be to test using the actual interface, not just using any network connectivity (might be hard to implement). We can add tests to iscsi to check if the proper network interface is up, but that will only allow us to speed up the start up process. If the network we need is not up, we can skip trying to login. Adding checks alone would not allow us to restart the iscsi service later when the network is up properly. The problem is iscsi does not start itself. Something like some hotplug scripts or init/systemd stuff calls it. It differs from distro to distro. That entity that calls iscsi would need to know that the network is up in a way iscsi can use it and then call iscsi. I think some distros just call iscsi anytime there is a network change like a interface coming up or a interface getting a address. 2. Or yes, an alternative fix might be to just increase the tryout number. 3. Or maybe what's happening is that since the interface doesn't exists it doesn't starts trying again, but terminates the whole process, since there was no interface at that time. I guess this was happening in my case. iscsi is going to try and do a connect() when it is started. It has zero smarts. It assumes when you tell it to login the network is ready to go. It is going to retry for the login retries count not matter what error is returned. This was actually added because we saw the host no reachable error case. Also, there is a bug in the Debian package, `modprobe scsi_transport_iscsi` is missing, while the other 2 modprobes are present. It'll take some time for everyone trying to install iscsi to You shouldn't need to modprobe scsi_transport_iscsi. The iscsi_tcp module depends on libiscsi which depends on scsi_transport_iscsi. If depmod has run ok, then when you load iscsi_tcp it should load iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi automatically. What error do you get when you run modprobe iscsi_tcp manually? figure out that this modprobe is missing and you have to add it manually to /etc/modules. Also, making a change like this permanent in modules isn't really an elegant solution, so adding that line in the Deb 6 packages would be important. Are the maintainers present on this forum? Sending a bug report for Debian is such a hassle, I'd be happy if I could just reach them here. I think so. Is it still Ritesh? -- 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?hl=en.
Re: Initiator name missing
Did you see my other mail? Previous mail: --- You have a older version. Just rm the old setup files: rm /etc/iscsi/nodes rm /etc/iscsi/send_targets or your version/distro might put it in /var/lib rm /var/lib/iscsi/nodes rm /var/lib/iscsisend_targets Also make sure that in iscsid.conf both the discovery username/password and node username/password settings are removed. - You can hand edit those files if you want, but we do not support that. They can change at any time. Where did you get your open-iscsi tools? Are they from the distro or open-iscsi.org? If you clear the username settings in iscsid.conf, then run the normal old iscsiadm discovery command it should have cleared out the old settings. On 01/09/2013 01:09 PM, Jeff Bye wrote: Hello again Mike / open-iscsi community, Any clue as to what might be missing for me? Is there a way to update by editing a file as opposed to typing in the commands? It seems so close to being figured out but I'm stumped! Thanks again Jeff On Fri, Jan 4, 2013 at 4:37 PM, Jeff Bye jeff...@gogoluckey.com mailto:jeff...@gogoluckey.com wrote: 2.0-871 is what I'm running Jeff On Fri, Jan 4, 2013 at 4:17 PM, Jeff Bye jeff...@gogoluckey.com mailto:jeff...@gogoluckey.com wrote: I tried all of the commands and none of them worked for me: *deadlineserver@deadlineserver ~ $ iscsiadm -m discoverydb -t st -p 10.10.0.1:3260 http://10.10.0.1:3260 -o delete* iscsiadm -m discovery [ -hV ] [ -d debug_level ] [-P printlevel] [ -t type -p ip:port -I ifaceN ... [ -l ] ] | [ -p ip:port ] [ -o operation ] [ -n name ] [ -v value ] iscsiadm -m node [ -hV ] [ -d debug_level ] [ -P printlevel ] [ -L all,manual,automatic ] [ -U all,manual,automatic ] [ -S ] [ [ -T targetname -p ip:port -I ifaceN ] [ -l | -u | -R | -s] ] [ [ -o operation ] [ -n name ] [ -v value ] ] iscsiadm -m session [ -hV ] [ -d debug_level ] [ -P printlevel] [ -r sessionid | sysfsdir [ -R | -u | -s ] [ -o operation ] [ -n name ] [ -v value ] ] iscsiadm -m iface [ -hV ] [ -d debug_level ] [ -P printlevel ] [ -I ifacename ] [ [ -o operation ] [ -n name ] [ -v value ] ] iscsiadm -m fw [ -l ] iscsiadm -m host [ -P printlevel ] [ -H hostno ] iscsiadm -k priority *I checked man iscsiadm and found:* -m, --mode op specify the mode. op must be one of discovery, node, fw, host iface or session. If no other options are specified: for discovery and node, all of their respective records are displayed; for session, all active sessions and connections are displayed; for fw, all boot firmware values are displayed; for host, all iSCSI hosts are displayed; and for iface, all ifaces setup in /etc/iscsi/ifaces are displayed. Am I running the wrong version perhaps? Jeff On Thu, Jan 3, 2013 at 7:05 PM, Mike Christie micha...@cs.wisc.edu mailto:micha...@cs.wisc.edu wrote: The iscsid.conf values are the defaults one used to setup the port/node/target db. If you clear the iscsid.conf values, you would still need to update the db ones for it to take effect on existing targets you have already setup. For the discovery values you can either delete the old discovery record: iscsiadm -m discoverydb -t st -p ip -o delete When you run the discovery command next, then it will use the iscsid.conf settings to create the discovery record. or if your tools does not support that command you can clear the chap settings iscsiadm -m discoverydb -t st -p ip -o update -n discovery.sendtargets.auth.username -v iscsiadm -m discoverydb -t st -p ip -o update -n discovery.sendtargets.auth.password -v iscsiadm -m discoverydb -t st -p ip -o update -n discovery.sendtargets.auth.authmethod -v none On 01/03/2013 01:46 PM, Jeff Bye wrote: Hey! I've been out of town for a couple of weeks. Hope you had a chance to take some time off as well :) It seems that the username and password I had initially set up is still being used, however in iscsid.conf CHAP is set to none and any other information has been commented. Does this only affect the target side? Jeff When I had it running on a windows machine (a temporary
Re: Problem with auto-starup on Debian 6
On Thu, 2013-01-10 at 00:24 -0600, Mike Christie wrote: I think some distros just call iscsi anytime there is a network change like a interface coming up or a interface getting a address. Ubuntu (and I'd guess Debian) does this (well, the on ifup part). It also stops open-iscsi on ifdown. I just had to disable that today. Imagine a virtualization host server. You create a new VM on a new VLAN. You add the relevant bridge interface, bring it up, and *bam*, all your existing, running VMs just lost access to their disks. Likewise, you can't upgrade the open-iscsi package while anything is using iSCSI devices, because it will stop and start the service. I solved these problems by using dpkg-divert on the if-up.d and if-down.d scripts to move them to open-iscsi.disabled and a custom policy-rc.d script to disallow open-iscsi stops or restarts if any VMs are running. Also, at least in my case, it's necessary to restart libvirt-bin after restarting open-iscsi. Are many people really using iSCSI via roaming network connectivity? -- Richard signature.asc Description: This is a digitally signed message part
