Jim,
Yes. There was a /core file. Unfortunately, I appears to be from today (from
my attempts to debug this), and not from when I started having this problem.
In an attempt to try this problem from a different angle, I decided to ditch
the ZFS iscsi management and try COMSTAR. So,
# pkg install SUNWstmf
I went through the COMSTAR documentation and set up the LUNs:
# sbdadm create-lu /dev/zvol/rdsk/tank/iscsi_LUNS/vol001
# sbdadm create-lu /dev/zvol/rdsk/tank/iscsi_LUNS/vol002
# sbdadm list-lu
Found 2 LU(s)
GUID DATA SIZE SOURCE
-------------------------------- ------------------- ----------------
600144f0000827b52b834a37f5540001 322122481664
/dev/zvol/rdsk/tank/iscsi_LUNS/vol001
600144f0000827d7f05e4a37eeb10002 161061208064
/dev/zvol/rdsk/tank/iscsi_LUNS/vol002
Now, after a reboot:
# sbdadm list-lu
Found 1 LU(s)
GUID DATA SIZE SOURCE
-------------------------------- ------------------- ----------------
600144f0000827d7f05e4a37eeb10002 161061208064
/dev/zvol/rdsk/tank/iscsi_LUNS/vol002
600144f0000827b52b834a37f5540001 <Failed to load>
/dev/zvol/rdsk/tank/iscsi_LUNS/vol001
although "zfs list" still shows it's there. I suspect the "<Failed to
load>" here is the same thing that's affecting ZFS when ZFS tries to manage
the iSCSI share.
Any more thoughts/ideas?
Also, on another note, I can't seem to execute the target service outlined in
the COMSTAR documentation:
# svcadm enable -r svc:/network/iscsi/target:default
svcadm: Pattern 'svc:/network/iscsi/target:default' doesn't match any instances
Where do I get the target service from?
Thank you!
Mark
--
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
