Given that I’m neither a Solaris expert (yet) nor an iSCSI expert (yet), I knew that it would be a bit of a challenge to make this work. Fortunately, a found a very useful blog posting by Frank Berger that gave me the framework I needed to get started. From there, Sun’s documentation provided the rest of the necessary details. Perhaps this documentation will prove moderately useful as well.
First, I added the following lines to the /etc/ietd.conf on the CentOS iSCSI target server:
Target iqn.2006-08.net.example:server.lun1 IncomingUser username complicatedpassword Lun 1 Path=/dev/vg00/isanvol1,Type=fileio Alias iet-lun1 MaxConnections 8 InitialR2T No ImmediateData Yes
A quick restart of the iSCSI target service and I was all set on the target side. If you were going to do this yourself in your own environment, you’d need to modify the â€œIncomingUserâ€ and â€œLun X Pathâ€. In this instance I’m using LVM on CentOS, so my path specifies a logical volume in a volume group. Your configuration will differ, obviously. Alternately, if you are using a different iSCSI target implementation, you’d need to configure it appropriately. (I hope to be able to do some testing against a NetApp iSCSI target in the near future.)
On the initiator side, everything is done with the â€œiscsiadmâ€ command. This command is fairly self-explanatory and has built-in help (-?) throughout most of the options, but it did take me a little bit of time to get things working.
First, we have to make sure that the iSCSI initiator is online:
svcs -a | grep iscsi
If disabled, then we can enable it with this command:
svcadm enable svc:/network/iscsi_initiator
From there, we configure the iSCSI initiator:
iscsiadm add discovery-address 10.1.1.1:3260 iscsiadm modify initiator-node -a CHAP iscsiadm modify initiator-node -H username iscsiadm modify initiator-node -C (specify CHAP password) iscsiadm modify discovery --sendtargets enable
Because I’d also specified a static config as well (dynamic discovery didn’t seem to be working as I expected; more on that in a moment), using â€œiscsiadm list targetâ€ now returned two iSCSI targets. They appeared to be different targets, and since I do have two targets defined on the iSCSI server (one for VMware and one for this), I didn’t want to take any chances on affecting the VMware LUN. So, I removed and disabled the dynamic discovery, removed the static config, and then re-added the static config:
iscsiadm add static-config iqn.2006-08.net.example:server.lun1, 10.1.1.1:3260
(This should all be on one line; it was wrapped here for readability.) After doing that, â€œiscsiadm list targetâ€ showed only a single target identified as â€œserver.lun1â€, which assured me that I wasn’t seeing the VMware LUN.
<aside>In a more complex environment, how does one ensure that iSCSI LUNs are properly isolated from unwanted hosts? The â€œIncomingUserâ€ parameter was different between my VMware LUN and the raw LUN being presented to Solaris, so in theory I would have been safe. Better safe than sorry, in my opinion.</aside>
After I was sure that the iSCSI initiator was properly seeing the LUN, then I created a new device, created a new filesystem on that device, and then mounted it:
devfsadm -c iscsi format (selected new disk identified as iSCSI) newfs /dev/dsk/c2t1d0s2 mount /dev/dsk/c2t1d0s2 /export/iscsi
Of course, you’ll need to modify the above commands slightly depending upon your configuration, but the overall process should be pretty close to what I’ve outlined above.