Network and Storage Protocols
Network and Storage Protocols
Hello, all!
I've a bit a puzzle here regarding iSCSI services. Namely, when rebooted, one of our systems tried to start iSCSI automatically - as it should - but the very next second it, the service was stopped. Here's the Autosupport segment describing it:
Sat Nov 7 15:28:12 CET [dfu.firmwareUpToDate:info]: Firmware is up-to-date on all disk drives
Sat Nov 7 15:28:12 CET [sfu.firmwareUpToDate:info]: Firmware is up-to-date on all disk shelves.
Sat Nov 7 15:28:15 CET [10/100/1000/e0b:info]: Ethernet e0b: Link up
Sat Nov 7 15:28:15 CET [10/100/1000/e0a:info]: Ethernet e0a: Link up
Sat Nov 7 15:28:17 CET [iscsi.service.startup:info]: iSCSI service startup
Sat Nov 7 15:28:18 CET [rc:ALERT]: timed: time daemon started
Sat Nov 7 15:28:18 CET [iscsi.service.shutdown:info]: iSCSI service shutdown
Sat Nov 7 15:28:19 CET [mgr.boot.disk_done:info]: NetApp Release 7.2.5.1 boot complete. Last disk update written at Sat Nov 7 13:23:25 CET 2009
Sat Nov 7 15:28:20 CET [mgr.boot.reason_ok:notice]: System rebooted.
Needles to say, none of the servers couldn't establish iSCSI connections. Any thoughts on what might've caused this?
Thanks,
Igor
Hi Igor,
Do you have the iSCSI license? Maybe, you have a demo license and the time for this expired.
See you!
Yes Rodrigo,
I have an iSCSI licence. A simple iscsi start command was enough to get it going again, no problem... And, as you can see, the syslog message is an "info" level record. It's not critical or anything --> http://now.netapp.com/NOW/ems/systrans_sev_levels.htm
I'm just wondering what could've stopped the service during the system boot-up sequence... It makes no sense.
Did you add iscsi start/stop in /etc/rc file ? .
Thanks;
Daniel
Hiya, Daniel!
No, there was no need. iSCSI was always started automatically.
However, since I've have no idea what stopped it, I've added an iscsi start line at the end of my simulator's /etc/rc script - here's what I got:
Mon Nov 9 08:51:00 CET [netif.linkUp:info]: Ethernet ns0: Link up.
add net default: gateway 192.168.0.1
iscsi: service not ready
Mon Nov 9 08:51:00 CET [iscsi.service.startup:info]: iSCSI service startup
Mon Nov 9 08:51:01 CET [rc:ALERT]: timed: time daemon started
Mon Nov 9 08:51:01 CET [perf.archive.start:info]: Performance archiver started. Sampling 22 objects and 192 counters.
Mon Nov 9 08:56:03 CET [mgr.boot.disk_done:info]: NetApp Release 7.3.1 boot complete. Last disk update written at Mon Nov 9 08:55:30 CET 2009
Mon Nov 9 08:56:03 CET [mgr.boot.reason_ok:notice]: System rebooted after a reboot command.
CIFS local server is running.
It would appear that adding iscsi start doesn't help, since the service is not yet ready to be administered. At least not on the simulator, but I think it's the same thing with real filers...
I need to execute that command after the system has fully rebooted. How do I do that?
Is the option iscsi.enable set to "on"?
Yup.
Otherwise I wouldn't have gotten that line:
Sat Nov 7 15:28:17 CET [iscsi.service.startup:info]: iSCSI service startup
Hi ,
>>>iscsi: service not ready
From the above log it seems to be some config issue with Multistore. Can you check 'vfiler status -a' to identify iscsi protocol is allowed for vfiler0 and if not do the following
danielpr1> vfiler status -a
vfiler0 running
ipspace: default-ipspace
IP address: 10.72.184.52 [ns0]
Path: / [/etc]
UUID: 00000000-0000-0000-0000-000000000000
Protocols allowed: 6
Allowed: proto=rsh
Allowed: proto=ssh
Allowed: proto=nfs
Allowed: proto=cifs
Allowed: proto=ftp
Allowed: proto=http
Protocols disallowed: 1
Disallowed: proto=iscsi
danielpr1> vfiler allow vfiler0 proto=iscsi
danielpr1>
Thanks
Daniel
I don't have Multistore licensed on my ONTAP Simulator (nor on my filer), but that's interesting... is there a regular command that performs that kind of check?
You can add the multistore license and check the vfiler status for Vfiler0 on your simulator.
Thanks
Daniel
simulator> vfiler status -a
vfiler0 running
ipspace: default-ipspace
IP address: 192.168.0.150 [ns0]
Path: / [/etc]
UUID: 00000000-0000-0000-0000-000000000000
Protocols allowed: 7
Allowed: proto=rsh
Allowed: proto=ssh
Allowed: proto=nfs
Allowed: proto=cifs
Allowed: proto=iscsi
Allowed: proto=ftp
Allowed: proto=http
Protocols disallowed: 0
I guess this means that iSCSI protocol is enabled by default, and I haven't made any changes to configuration on the real filer either so... there has to be something else. I've opened up a case, and I'll post any findings here.