Mark,
Thanks for the ideas, Mike.
# svccfg -s iscsitgt listprop | grep backing-store
I checked the backing-store property and there isn't one. I'm using
ZFS shareiscsi to make the iscsi targets and I'm not sure what ZFS
does with the backing-store command.
When using ZFS and shareiscsi, the backing store proprty data
associated with an iSCSI Target LUN is stored as properties of the
ZVOL, and do not existing within SCF (svccfg). This is so the
properties follow a "zpool export ...", "zpool import ...", where the
ZFS storage pool may have moved between systems.
For each of the ZVOLs that have been provisioned and tagged with the
shareiscsi property, the following ZFS outputs are available:
For example:
# zfs create -s -V 1g pool-0/lun0
# zfs set shareiscsi=on pool-0/lun0
# iscsitadm list target
Target: pool-0/lun0
iSCSI Name: iqn.1986-03.com.sun:02:1fb66f28-b703-ece2-cb26-
ad612fab1909
Connections: 0
# zfs list -o shareiscsi pool-0/lun0
SHAREISCSI
on
# zfs list -o iscsioptions pool-0/lun0
ISCSIOPTIONS
<target in-core='true'><lun-list><lun version='1.0'>0<status>online</
status><interleave>1</interleave><bps>512</bps><spt>16</
spt><cylinders>32768</cylinders><heads>4</heads><rpm>7200</
rpm><dtype>disk</dtype><vid>SUN</vid><pid>SOLARIS</pid><guid>0</guid></
lun></lun-list><iscsi-name>iqn.1986-03.com.sun:02:1fb66f28-b703-ece2-
cb26-ad612fab1909</iscsi-name></target>
You may be running into a problem where the iSCSI Target Daemon has
restarted, causing the daemon to forget all ZVOLs. ZFS should re-
registering those ZVOLs tagged with the shareiscsi property.
An indication of this failure, is a /core file in the system's root
directory, or alternate locatation as configured through "coreadm".
This can be verified by issuing: "file /core" (or way coreadm is so
configured), and if file states "iscsitgtd" as this image, there a
defect worthy of investigation.
You can test this theory by turning the properrty off, then on the
shareiscsi property
# zfs set shareiscsi=off pool-0/lun0
# zfs set shareiscsi=on pool-0/lun0
# iscsitadm list target
- Jim
Does this make sense?
http://blog.laspina.ca/ubiquitous/provisioning_disaste
r_recovery
Oh. The MAC initiator should be checked for CHAP
remnants and cleared of them if they exist.
That is cleaned out.
Thanks!
Mark
--
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
