Let me correct my previous post.
It turns out that what I previously described was a symptom of having
added those initiators to the ACLs of my ZFS LUN. It seems that if you
create local names for initiators, and then add those initiators to that
ACLs of ZFS LUNs, this sort of overrides their initial creation. So when
I run "iscsitadm list initiator" before adding them to the ACLs, I get
the output:
Initiator: local1
iSCSI Name: one
CHAP Name: Not set
Initiator: local2
iSCSI Name: two
CHAP Name: Not set
But once I add them to the ACLs of my ZFS LUN, I get the output:
Initiator: one
iSCSI Name: Not set
CHAP Name: Not set
Initiator: two
iSCSI Name: Not set
CHAP Name: Not set
while the SMF properties stay the same. Why would this be the case, and
is this fixable?
Joel Weinberger wrote:
> I've been experimenting with iscsi's initiator naming facility, and it
> appears to have some strange properties. When I run the command,
> "iscsitadm create initiator --iqn <some iqn> local1," everything seems
> to work. I check svc:/system/iscsitgt and it has the appropriate
> property group and properties for the newly named local-initiator.
>
> However, if I modify the property "iscsi-name," for example, and refresh
> the iscsitgt service, nothing happens. Even stranger, when I restart the
> service and run "iscsitadm list initiator," it does not list any
> initiators. It turns out, this happens regardless of whether I modified
> the SCF property. Furthermore, if I run "iscsitadm create initiator
> --iqn <some iqn> local1," again after a restart, and then I run
> "iscsitadm list initiator," there are now two entries for "local1."
>
> Any ideas about this behavior, which I found rather unexpected?
>
>
--
Joel Weinberger, Fishworks
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
