I have an interesting problem. Box is snv_80. # svcs iscsitgt STATE STIME FMRI online 16:23:16 svc:/system/iscsitgt:default
I've made a bunch of ZFS zvols and presented them as iSCSI targets, using the 'zfs set shareiscsi=on' command. Some time later I made another target using iscsitadm, called "ponies", with UFS backing store /cheval. I then set some logging level and refreshed. # svccfg -s iscsitgt setprop iscsitgt/qlog-lvl = integer: 0xffffffff Some time later I needed to stop logging, because I didn't check for the original value of iscsitgt/qlog-lvl before I changed it, I decided to rollback to the initial snapshot. After the refresh, my "ponies" target disappeared, but all the zvol targets remained. This bothers me for a few reasons: 1) This is not what I intend to happen. In my mind, something like logging is OK for SMF control but I didn't expect my iSCSI configuration to enter the repository. We've had a few threads about what should be configurable under SMF, and the original answer used to be "everything" but for practicality this is not a good or do-able answer. 2) In a simpler, less nuanced view, what I didn't use SMF to configure, I shouldn't lose through SMF. I used iscsitadm to create my target, while it's acceptable that I could lose my target by blowing away a config file or trashing a device label, I didn't expect it to be in an SMF snapshot. Should I expect this going forward? This seems an admin trap to me. There didn't seem to be a way to set debug level from iscsitadm directly. 3) ZFS zvol target info is kept somewhere else, obviously, because I didn't lose those. This inconsistency is a burr. Should I open up a bug about this usage, it seems like it could be "friendlier" somehow, or just get used to this, the way of the future? CT
