Hi Carlopmart:
Yes, but you should do the zfs umount and export manually. In fact that
this work may be not necessary. If you do that, after the system reboot,
you should re-import the zpool from iscsi target if you want to use them
next time.
Regards,
Bing
carlopmart wrote:
Thanks Bing, but only one question. Is it possible to umount all zfs
volums and zpools (only disks that are connected by iscsi initiator)
before launching the shutdown or reboot command??
Bing Zhao - Sun Microsystems wrote:
Hi Carlopmart:
It seems that before shutdown the machine, some of the iscsi luns on
the iscsi initiator side are still being used.
So when shutdown, iscsi initiator can't logout from the target
because of these luns.
The iscsi discovery failure log is also caused by this. This behavior
is not harmful. Don't worry about it.
If you shutdown through the desktop and there are some iscsi luns
being used, the shutdown time is longer than usual.
You can use terminal to shutdown or reboot the machine as workaround.
Please have a try. Hope it is helpful.
Regards,
Bing
carlopmart wrote:
Hi all,
I having problems using iscsi initiator under opensolaris. I can to
connect to two iscsi targets (one Solaris 10u8 based and another
opensolaris 2009.06) without problems. I can create zfs volums,
erase files, create files, etc ... all works ok. But problems
appears when I try to shutdown or reboot this opensolaris
workstation, then these errors appears:
Nov 11 16:01:51 mordor iscsi: [ID 213721 kern.notice] NOTICE: iscsi
session(20) - session logout failed (1)
Nov 11 16:01:51 mordor iscsi: [ID 213721 kern.notice] NOTICE: iscsi
session(17) - session logout failed (1)
Nov 11 16:01:51 mordor iscsi: [ID 213721 kern.notice] NOTICE: iscsi
session(9) - session logout failed (1)
Nov 11 16:01:51 mordor iscsi: [ID 213721 kern.notice] NOTICE: iscsi
session(6) - session logout failed (1)
Nov 11 16:01:51 mordor iscsi: [ID 882656 kern.notice] NOTICE: iscsi
discovery failure - StaticTargets method is not enabled
Nov 11 16:01:51 mordor iscsi: [ID 299153 kern.notice] NOTICE: iscsi
discovery failure - iSNS method is not enabled
At this moment I need to wait between four or five minutes until an
iscsi initiator error appears:
Nov 11 16:44:16/3: svc:/network/iscsi/initiator:default: Method or
service exit timed out. Killing contract 35.
Nov 11 16:44:16/197: network/iscsi/initiator:default failed:
transitioned to maintenance (see 'svcs -xv' for details)
then workstation reboots or stops ... When this workstation starts
up, all iscsi disks are reconnected without problems and under dmesg
any error appears.
On network-iscsi-initiator:default.log exists these entries:
bash-3.00# cat network-iscsi-initiator:default.log
[ Nov 11 15:44:59 Enabled. ]
[ Nov 11 15:44:59 Rereading configuration. ]
[ Nov 11 15:45:00 Executing start method ("/lib/svc/method/iscsid") ]
[ Nov 11 15:45:00 Method "start" exited with status 0 ]
[ Nov 11 15:51:57 Stopping because service disabled. ]
[ Nov 11 15:51:57 Executing stop method (:kill) ]
[ Nov 11 15:53:00 Enabled. ]
[ Nov 11 15:53:06 Executing start method ("/lib/svc/method/iscsid") ]
[ Nov 11 15:53:07 Method "start" exited with status 0 ]
[ Nov 11 16:01:51 Stopping because service disabled. ]
[ Nov 11 16:01:51 Executing stop method (:kill) ]
[ Nov 11 16:11:51 Method or service exit timed out. Killing contract
33 ]
[ Nov 11 16:12:50 Enabled. ]
[ Nov 11 16:12:58 Executing start method ("/lib/svc/method/iscsid") ]
[ Nov 11 16:13:01 Method "start" exited with status 0 ]
iscsi initiator discovery options are configrued like this:
bash-3.00# iscsiadm list discovery
Discovery:
Static: disabled
Send Targets: enabled
iSNS: disabled
I have tested this configuration on a solaris 10u8 workstation and
problems continues. On the other side, I haver several linux and
windows 2008 clients connected to these targets without problems:
they can to connect, disconnect and reconnect without issues.
Where is the problem?? Do I need to modify some iscsi initiator param??
Many thanks.
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org