Re: Unable to discover targets after initrd boot because iscsid database is lost.
Matthew Schumacher wrote: Mike Christie wrote: I found another issue: When using open-iscsi-2.0_869.2 on 2.6.24.5 everything works as described above. You can restart iscsid and all is well. If I switch to open-iscsi-2.0_871_2 Where did you get 871.2? There is only a 871 on open-iscsi.org. I think I can hit this. The problem seems to be we are trying to bind a session when we should not be. I will make a up a patch for testing. The problem I am seeing only occurs if you have do not have a record when you restart iscsid. In this case, we will use the settings in sysfs, but this also includes the local ip address. For software iscsi we cannot bind by ip address, and we will try to set up the offload stuff, so we either fail to reconnect or we might fail in a crazier way. Your right, it's just plain 871. I must have put the .2 on because of 869.2. Anyway, I doubt this is a problem in the user space because I can use iscsid from either version just fine as long as I use the modules from 869.2. If I use the modules and user space from 871 then restarting iscsid causes a lost connection. I just tried that combo and it worked for me. Could you try all 871 stuff, and run iscsid like this iscsid -d 8 -f This will redirect lots of log output to the console. Can you send that? --~--~-~--~~~---~--~~ 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: Unable to discover targets after initrd boot because iscsid database is lost.
Matthew Schumacher wrote: Mike Christie wrote: When you kill iscsid, are there sessions running? If there are then when you run iscsid below you should not have to rerun your discovery command and run the login command. iscsid basically looks at /sys/class/iscsi_session and will logout those session and then relogin to make sure they are in sync with iscsid and the kernel. If you are running the discovery command and login command below to login into other targets then it is fine. Mike, I can confirm that this works as you say using linux 2.6.24.5, however with linux 2.6.30.2 the iscsi disk breaks if I don't also call discovery. I'm not sure why this is, but thought I would mention it. Thanks, schu I found another issue: When using open-iscsi-2.0_869.2 on 2.6.24.5 everything works as described above. You can restart iscsid and all is well. If I switch to open-iscsi-2.0_871_2 (still on 2.6.24.5) then when I kill iscsid and start it again then the host locks every time because the target goes away. If I cache the iscsid and iscsiadm apps then try and login I get: iscsiadm: initiator reported error (15 - already exists) So if I try and logout (so that I can log back in) I get: iscsiadm: initiator reported error (9 - internal error) I'm not sure why this would be but for whatever reason the 869.2 iscsid finds it's sessions after a restart while the 871.2 iscsid never figures out what is going on and the session is lost causing a crash since this host uses iscsi for root. If there is any debugging I can provide let me know... schu --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Unable to discover targets after initrd boot because iscsid database is lost.
Hello Group,
I'm working out the config to boot a host from an iscsi target and have
everything pretty much working, but once the host is up, I can't connect
to any other iscsi targets.
My initrd script calls the following:
-
# bring up iscsi
/sbin/iscsid
# connect to the share
/sbin/iscsiadm -m discovery -t sendtargets -p ${ISCSI_PORTAL}
/sbin/iscsiadm -m node -T ${ISCSI_TARGET} -p ${ISCSI_PORTAL} -l
# mount and switch_root
mount -o ro -t $ROOTFS $ROOTDEV /mnt
umount /proc
umount /sys
exec switch_root /mnt /sbin/init
-
Which correctly brings up the iscsi disk and starts init, but once the
machine is up I can't discover targets anymore:
r...@host:~# /sbin/iscsiadm -m node -T mail -p 192.168.x.101:3260 -l
Logging in to [iface: default, target: mail, portal: 192.168.x.101,3260]
r...@host:~#
I suspect that the problem is that iscsid continues to run from the
initrd image where it stores it's session database which is lost when I
switch_root.
I tried restarting iscsid after boot, but the second I do that I loose
my disk and my host crashes.
I did some searching on google for a solution, but don't really see
anything, can someone point me in the right direction or tell me how to
handle restarting iscsid?
Thanks,
schu
--~--~-~--~~~---~--~~
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: Unable to discover targets after initrd boot because iscsid database is lost.
Matthew Schumacher wrote:
Hello Group,
I'm working out the config to boot a host from an iscsi target and have
everything pretty much working, but once the host is up, I can't connect
to any other iscsi targets.
My initrd script calls the following:
-
# bring up iscsi
/sbin/iscsid
# connect to the share
/sbin/iscsiadm -m discovery -t sendtargets -p ${ISCSI_PORTAL}
/sbin/iscsiadm -m node -T ${ISCSI_TARGET} -p ${ISCSI_PORTAL} -l
# mount and switch_root
mount -o ro -t $ROOTFS $ROOTDEV /mnt
umount /proc
umount /sys
exec switch_root /mnt /sbin/init
-
Which correctly brings up the iscsi disk and starts init, but once the
machine is up I can't discover targets anymore:
r...@host:~# /sbin/iscsiadm -m node -T mail -p 192.168.x.101:3260 -l
Logging in to [iface: default, target: mail, portal: 192.168.x.101,3260]
r...@host:~#
I suspect that the problem is that iscsid continues to run from the
initrd image where it stores it's session database which is lost when I
switch_root.
Yeah, when you run iscsid from the initrd then when you run iscsiadm -m
discovery ... it will store the db info in the /etc/iscsi/nodes of the
initrd FS.
I tried restarting iscsid after boot, but the second I do that I loose
my disk and my host crashes.
This is what we do in Red Hat. It is a little tricky, because when
iscsid restarts it relogins into the target to make sure its state is
all in sync with the kernel and session. So the network has to be up
first, then restart iscsid. iscsid will then kill the running session
and relogin. There will be a delay of a couple seconds at this time, but
it should relogin and then the boot process should proceed.
--~--~-~--~~~---~--~~
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: Unable to discover targets after initrd boot because iscsid database is lost.
On 07/28/2009 06:59 PM, Matthew Schumacher wrote: Mike Christie wrote: This is what we do in Red Hat. It is a little tricky, because when iscsid restarts it relogins into the target to make sure its state is all in sync with the kernel and session. So the network has to be up first, then restart iscsid. iscsid will then kill the running session and relogin. There will be a delay of a couple seconds at this time, but it should relogin and then the boot process should proceed. This seems to work: --- #!/bin/sh # cache this stuff iscsid /dev/null iscsiadm /dev/null killall iscsid When you kill iscsid, are there sessions running? If there are then when you run iscsid below you should not have to rerun your discovery command and run the login command. iscsid basically looks at /sys/class/iscsi_session and will logout those session and then relogin to make sure they are in sync with iscsid and the kernel. If you are running the discovery command and login command below to login into other targets then it is fine. iscsid iscsiadm -m discovery -t sendtargets -p 192.168.x.101:3260 iscsiadm -m node -T database -p 192.168.x.101:3260 -l --- Does that look sane to you? It does pause for 20 seconds, but appears to work. Do you know why it pauses? Because when iscsid restarts it will logout the running sessions then relogin. I do not think it should take 20 seconds, but it could depending on your network and target. Also, thank you very much for your help with this, you have saved me a tremendous amount of time and for that I appreciate it. No problem. Next time use a distro that just has this stuff done 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 -~--~~~~--~~--~--~---
