It does NOT "come with the territory" of unique identifiers. If i can set the iqn within my own domain-name space (which every other iscsi product permits) i can ensure a lack of collisions myself, by policy.
Maybe this should not be a zfs paramiter, just adding support for doing this using iscsitgtd would make me happy. Additionally the aguement that it doesnt fit well with the shareiscsi paramiter (in Mike La Spina's post) is weak at best, because of the limited subset of the features that iscsitgtd provides which are availble using the shareiscsi support. What's one more limited-to-manually-making-targets feature? Although, if you are of the philosiphy that people should be using the shareiscsi method, then you really probibly should be exposing, as much as possible, the funtaionality by way of the zfs configuration method. Also in responce to Mike (sorry Jonn), I was getting "oh it will be in COMSTAR" last year. I said then, as I say now that will mean something to me when it's in a production-ready state. Until then it is of no more use to me then vaporware. I am fully aware this is open-source and what that means, which is why the offer I made last year to sponser a fix for this problem still stands. Anyone interested in the contract, feel free to contact me: [EMAIL PROTECTED] -- This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
