Giving Solaris Systems iSCSI IQNs That Make Sense
Posted on July 3, 2007
When working with iSCSI nothing can be more confusing and frustrating than dealing with WWN-like cryptic IQN’s (unique strings that identify an initiator or target). I mean, how meaningful is this?: iqn.1986-03.com.sun:02:a182b87b-41f0-661f-c161-8de3fe28c5ef Not very.
SysAdmin Rule #102: Take cryptic non-sensical string, add some sleep deprivation, insert into production environment, result? Disaster.
Thankfully changing that random string is easy. (see target.h for how that string is determined)
First, find out what your initiators IQN is by default:
root@aeon ~$ iscsiadm list initiator-node Initiator node name: iqn.1986-03.com.sun:01:e00000000000.464d05f9
Now change it like so:
root@aeon ~$ iscsiadm modify initiator-node --node-name iqn.1998-07.com.cuddletech:aeon root@aeon ~$ iscsiadm list initiator-node Initiator node name: iqn.1998-07.com.cuddletech:aeon ...
Sweet and simple. Just remember to craft your IQN’s by the rules:
See Section 184.108.40.206.1 of RFC 3720 – Internet Small Computer Systems Interface (iSCSI): “Type “iqn.” (iSCSI Qualified Name)”
Please note that Target IQN’s may not be changed. Each Target is given a unqiue IQN and while you can change the Alias of a Target, you can’t change the IQN. This isn’t really a problem most of the time, however, because unlike NetApp Filers where a single storage system has a single IQN which is LUN masked, each Target has its distinct IQN. Besides that, the string used for the SCSI Target ID (ie: c2t0912309812039810983d0) is going to be funky anyway, nothing you can do about that. (That funky string is actually the targets GUID.)