Summary: iSCSI basics and implementation examples on AIX, linux and VMware ESXi.
Date: Around 2014
Refactor: 29 December 2024: Checked links and formatting. Removed older content.

Terminology: iSCSI (for “Internet SCSI”) is a protocol that allows clients (called initiators) to send SCSI commands (CDBs) to SCSI storage devices (targets) on remote servers. It is a popular Storage Area Network (SAN) protocol, allowing organizations to consolidate storage into data center storage arrays while providing hosts (such as database and web servers) with the illusion of locally-attached disks. Unlike Fibre Channel, which requires special-purpose cabling, iSCSI can be run over long distances using existing network infrastructure.
IQN is the iSCSI Qualified Name and has the format iqn.yyyy-mm.<reversed domain name>.<scsi alias and or hash>

The default TCP ports for iSCSI are 860 and 3260.

Source and more information on wikipedia: http://en.wikipedia.org/wiki/ISCSI

The implementation of the initiation software in AIX is covered in two steps:

1. Install the software
2. Connect to the target server

You need to install the software using the software supplied by the iSCSI target supplier. In this case it's Netapp:

• tar -xf netapp_aix_SAN_kit_1.1.tar
• cd netapp_aix_SAN_kit_1.1
• ./install

Running the install script choose to install the kit and the iSCSI software. You don't need the FibreChannel software, so don't install it. Reboot the server after the installation.

To connect to the target server you have to complete these steps:

1. Configure the network card connected to the SAN
2. Define the target server
3. Create iSCSI nodename
4. Discover the LUNS

In case you have a dedicated network you'll need to configure a dedicated NIC on the server to connect to the SAN. Using smitty go to “Communications Applications and Services”, select “TCPIP” and select “Minimum Configuration & Startup”. In this menu you'll be able to configure your network card. You'll at least need the ip-address and the subnetmask. If the target server is in another subnet or VLAN you'll also need to know the gateway.

Using vi add the following line to /etc/iscsi/targets:

<ip-address> 3260 <iqn.1992-08.com.netapp:sn.12345678>

That is, the ip-address of the target server, the iSCSI port (3260 is the default) and the iSCSI nodename of the target server, in this case a netapp.

Than create the iSCSI nodename on the server using the next command:

• chdev -l iscsi0 -a initiator_name=iqn.1996-04.com.ibm:<ininame>

Note that <ininame> is the initiator name as defined on the target server. You can verify the previous command by issuing this command:

• lsattr -El iscsi0

You can discover the LUNS created at the target by issuing this command:

• cfgmgr -l iscsi0

And you can verify this by issuing this command:

• sanlun lun show all

You should now see the LUNS displayed. You can now add the discovered disks into an appropriate volume group.

On SLES or other suse core versions iSCSI is installed through yast. Start yast and go to Network Services → iSCSI initiator:
After you've selected this you might get a warning to install the software first. If so, follow the prompts to install. In case you have the proper installation servers selected this will give no problems. After the installation you'll see this screen:
The iSCSI initiator name is the name you need to configure on the target to be allowed to contact the iSCSI target. You also might want to change the Service Start from 'Manual' (default) to 'When booting'. After you've setup the iSCSI target to allow the iSCSI initiator to connect you can discover the device and connect to it. To do so, go to Discovered Targets and select Discovery. Fill in the ip-address of the target, and click next. If everything is going well, you'll receive the targets your initiator can connect to. Select the target you want to connect to and select 'Log In'. Fill in, if desired, the authentication credentials and select Next. If everything went fine you now have a connected target:
Note that the Start-UP default is manual. Select 'Toggle Start-Up' to change this. To use the storage simply go to Partitioner and partition your newly added storage:

Below are the types of iSCSI supported by VMware

Software iSCSI initiator is VMware code built into the VMkernel. It used standard network adapters.
Booting is supported for ESXi

A dependent hardware iSCSI initiator (or adapter) depends on VMware networking and on iSCSI configuration and management interfaced provided by VMware. This type of adapter presents a standard network adapter and iSCSI off-load functionality for the same port. To make this adapter functional , you must set up networking for the iSCSI traffic and bind the adapter and an appropriate VMkernel iSCSI port.
Booting is supported for ESXi
This type is supported since vSphere 4.1

An independent hardware iSCSI adapter handles all iSCSI and network processing and management.
Booting is supported for ESX

The initiator does not need to perform a discovery. The initiator knowns in advance all the targets and uses IP addresses and domain names to communicate with them.

Each time the initiator contacts a specified iSCSI server it sends a SendTargets request to the server. The server responds with a list of available targets to the initiator. The names and IP addresses of these targets appear as static targets in the vSphere Client. Removed targets may return on rescans, HBA reset or host reboot.

CHAP uses a three-way handshake to verify the identity of hosts and or targets. The verification is based on a predefined private value, called a CHAP secret. CHAP is supported on the adapter level. On this level, all targets use the same CHAP secret. For software iSCSI, also per-target CHAP secrets are supported.

The target authenticated the initiator, but the initiator does not authenticate the target. A CHAP secret must be specified for initiator to access the target.

Provides an additional level of security which enabled the initiator to authenticate the target. Different secrets must be used for target and initiator secrets.
This is available for software iSCSI only.

The host does not use CHAP and disable authentication if it is currently enabled.

The host prefers a non-CHAP connection but allows for authentication when the target requires it.
This is available for software iSCSI only.

The host prefers CHAP connections but can use nono-CHAP connections when the target requires it.

This option requires successful CHAP authentication. This option is required for mutual CHAP.
This is available for software iSCSI only.

If you disable CHAP on a system that requires CHAP authentication, existing iSCSI sessions remain active until you reboot your ESX/ESXi host or the storage system forces a logout. After the session ends, you can no longer connect to targets that require CHAP.