Setting Up Solaris iSCSI Targets and Initiators (Task Map)
Configuring Solaris iSCSI Targets and Initiators
Basically, configuring your Solaris iSCSI targets and initiators involves the following steps:
Identifying the hardware and software requirements
Configuring your IP network
Connecting and setting up your iSCSI target device
(Optional) Configure iSCSI authentication between the iSCSI initiator and the iSCSI target, if necessary
Configuring the iSCSI target discovery method
Creating file systems on your iSCSI disks
Monitoring your iSCSI configuration
The iSCSI configuration information is stored in the /etc/iscsi directory. This information requires
no administration.
iSCSI Terminology
Review the following terminology before configuring iSCSI targets and initiators.
Term |
Description |
|---|
Initiator |
The driver that initiates
SCSI requests to the iSCSI target. |
Target device |
Represents the iSCSI storage component. |
Discovery |
Discovery is
the process that presents the initiator with a list of available targets. |
Discovery method
|
Describes the way in which the iSCSI targets can be found. Three
methods are currently available:
Internet Storage Name Service (iSNS) - Potential targets are discovered by interacting with one or more iSNS servers. SendTargets – Potential targets are discovered by using a discovery-address. Static – Static target address is configured.
|
Configuring Dynamic or Static Target Discovery
Determine whether you want to configure one of the dynamic features or use
static iSCSI initiator targets to perform device discovery.
Dynamic device discovery – If an iSCSI node exposes a large number of targets, such as an iSCSI to Fibre-Channel bridge, you can supply the iSCSI node IP address/port combination and allow the iSCSI initiator to use the SendTargets features to perform the device discovery.
Two dynamic device discovery methods are available: SendTargets and iSNS.
SendTargets - If an iSCSI node exposes a large number of targets, such as an iSCSI to Fibre-Channel bridge, you can supply the iSCSI node IP address/port combination and allow the iSCSI initiator to use the SendTargets features to perform the device discovery.
iSNS - iSNS (Internet Storage Name Service) allows the iSCSI initiator to discover the targets to which it has access using as little configuration as possible. It also provides state change notification functionality to notify the iSCSI initiator when changes in operational state of storage nodes occur. To use the iSNS discovery option, you can supply the iSNS server address/port combination and allow the iSCSI initiator to query the iSNS servers that you specified to perform the device discovery. The default port for iSNS server is 3205. For more information about iSNS, see RFC 4171:
http://www.ietf.org/rfc/rfc4171.txt
The iSNS discovery service provides an administrative model to discover all targets in a network.
For more information about setting up the Solaris iSNS support, see Chapter 15, Configuring and Managing the Solaris Internet Storage Name Service (iSNS).
Static device discovery – If an iSCSI node has a small number of targets or if you want to restrict the targets that the initiator attempts to access, you can statically configure the target-name by using the following static target address naming convention:
target,target-address[:port-number]
You can determine the static target address from the array's management tool.
Note - Do not configure an iSCSI target to be discovered by both static and
dynamic device discovery methods. The consequence of using redundant discovery methods might
be slow performance when communicating with the iSCSI target device.
How to Prepare for a Solaris iSCSI Configuration
- Become superuser.
- Verify that the iSCSI software packages are installed.
# pkginfo SUNWiscsiu SUNWiscsir
system SUNWiscsiu Sun iSCSI Device Driver (root)
system SUNWiscsir Sun iSCSI Management Utilities (usr)
- Verify that you are running a Solaris Express 8/06 or later release.
- Confirm that your TCP/IP network is setup.
- Connect your iSCSI target devices and confirm that they are configured.
For example, determine if the iSCSI target device is reachable by using the
telnet command to connect to the iSCSI target device using port 3260. If
the connection is refused, see Troubleshooting iSCSI Configuration Problems.
For information about connecting your third-party iSCSI target devices, see your hardware documentation.
Setting Up Your Solaris iSCSI Target Devices
You can use the iscsitadm command to set up and manage your Solaris
iSCSI target devices, which can be disk or tape devices. For the device
that you select as your iSCSI target, you'll need to provide an equivalently
sized ZFS or UFS file system as the backing store for the
iSCSI daemon.
For information about setting up a Solaris iSCSI target device with ZFS, see
ZFS and Solaris iSCSI Improvements in ZFS Administration Guide.
After the target device is set up, use the iscsiadm command to identify
your iSCSI targets, which will discover and use the iSCSI target device.
For more information, see iscsitadm(1M) and iscsiadm(1M).
The basic process is as follows:
Identify the backing store directory – For each target and logical unit created, the iSCSI daemon needs to store some information. By default, the backing store for this device is also located within the base directory. So, if the host system has a large ZFS pool to use, it may be easiest and desirable to allow the daemon to store everything in that location. It the backing store needs to be spread out, it's possible during the creation of each logical unit to specify the backing store location.
Create the iSCSI target – By default, the CLI assumes the requested device type is an LBA of logical unit 0. If a pass through mode is desired for character devices, the -raw option must be used. After the creation of the first LUN, other LUNs might be created for the same iSCSI target by specifying -lun number.
The daemon starts a background task that initializes the LUN to zeros. If, during that initialization, the underlying file system becomes 100% full, the daemon removes the target. During this initialization, the LUN is marked as being offline and can't be used by an initiator. It is possible during this time, however, to have an initiator discover this LUN. The Solaris initiator waits until it receives an Inventory Change notification and then automatically brings the device online.
How to Create an iSCSI Target
- Become superuser.
- Identify the backing store directory.
For example:
# iscsitadm modify admin -d /export/sandbox
- Create an iSCSI target.
For example:
# iscsitadm create target --size 2g sandbox
- Display information about the iSCSI target.
For example:
# iscsitadm list target -v sandbox
- Set up your iSCSI initiator to discover and use this target.
For more information, see How to Configure iSCSI Target Discovery.
How to Configure iSNS Discovery for the Solaris iSCSI Target
If your network includes a third-party iSNS server or a Sun iSNS
server, you can set up iSNS target discovery on your Solaris iSCSI targets.
- Become superuser.
- Add the iSNS server information.
For example:
# iscsitadm modify admin --isns-server ip-address or hostname[:port]
Identify the ip-address of the iSNS server in your network.
This step adds the iSNS server information to all of the Solaris iSCSI
targets.
- Enable iSNS server discovery.
For example:
# iscsitadm modify admin --isns-access enable
This step enables iSNS discovery for all of the Solaris iSCSI targets.
Configuring Authentication in Your iSCSI-Based Storage Network
Setting up authentication for your iSCSI devices is optional.
In a secure environment, authentication is not required because only trusted initiators can
access the targets.
In a less secure environment, the target cannot determine if a connection request
is truly from a given host. In that case, the target can
authenticate an initiator by using the Challenge-Handshake Authentication Protocol (CHAP).
CHAP authentication uses the notion of a challenge and response, which means that
the target challenges the initiator to prove its identity. For the challenge/response
method to work, the target must know the initiator's secret key and the
initiator must be set up to respond to a challenge. Refer to
the array vendor's documentation for instructions on setting up the secret key on
the array.
iSCSI supports unidirectional and bidirectional authentication:
Unidirectional authentication enables the target to authenticate the identity of the initiator.
Bidirectional authentication adds a second level of security by providing a means for the initiator to authenticate the identity of the target.
How to Configure CHAP Authentication for Your iSCSI Initiator
This procedure assumes that you are logged in to the local system
where you want to securely access the configured iSCSI target device.
- Become superuser.
- Determine whether you want to configure unidirectional or bidirectional CHAP.
Unidirectional authentication enables the target to validate the initiator. This method is the default method. Complete steps 3–5 only.
Bidirectional authentication adds a second level of security by providing a means for the initiator to authenticate the target. Complete steps 3–9.
- Unidirectional CHAP – Set the secret key on the initiator.
For example, the following command initiates a dialogue to define the CHAP secret
key.
# iscsiadm modify initiator-node --CHAP-secret
Note - The CHAP secret length must be a minimum of 12 characters and a
maximum of 16 characters.
- (Optional) Unidirectional CHAP – Set the CHAP name on the initiator.
By default, the initiator's CHAP name is set to the initiator node name.
You can use the following command to change the initiator's CHAP name.
# iscsiadm modify initiator-node --CHAP-name new-CHAP-name
- Unidirectional CHAP – Enable CHAP authentication on the initiator after the secret has
been set.
# iscsiadm modify initiator-node --authentication CHAP
CHAP requires that the initiator node have both a username and password.
The username is typically used by the target to lookup the secret for
the given username. In the Solaris environment, the CHAP name is always set
to the initiator node name by default. The CHAP name can be set
to any length text that is less than 512 bytes. The 512-byte length
limit is a Solaris limitation. However, if you do not set the CHAP
name, it is set to the initiator node name upon initialization.
- Bidirectional CHAP – Enable bidirectional authentication parameters on the target.
For example:
# iscsiadm modify target-param -B enable eui.5000ABCD78945E2B
Disable bidirectional CHAP. For example:
# iscsiadm modify target-param -B disable eui.5000ABCD78945E2B
- Bidirectional CHAP – Set authentication method to CHAP on the target.
For example:
# iscsiadm modify target-param --authentication CHAP eui.5000ABCD78945E2B
- Bidirectional CHAP – Set the target device secret key on the target.
For example, the following command initiates a dialogue to define the CHAP secret
key.
# iscsiadm modify target-param --CHAP-secret eui.5000ABCD78945E2B
- Bidirectional CHAP - Set the CHAP name on the target.
By default, the target's CHAP name is set to the target name.
You can use the following command to change the target's CHAP name.
# iscsiadm modify target-param --CHAP-name target-CHAP-name
How to Configure CHAP Authentication for Your iSCSI Target
- Become superuser.
- Set up the CHAP secret name for the target.
A common convention is to use the host name for the secret name.
For example:
# iscsitadm modify admin -H stormpike
- Enter the CHAP secret.
The CHAP secret must be between 12 and 16 characters. For example:
# iscsitadm modify admin -C
Enter secret: xxxxxx
Re-enter secret: xxxxxx
- Create an initiator object that will be associated with one or more targets.
This is done so that you can associate a friendly name (normally the
host name, in this case monster620) with the IQN value instead of
typing it in every time. For example:
# iscsitadm create initiator -n iqn.1986-03.com.sun: 01:00e081553307.4399f40e monster620
- Provide the same CHAP name that was used on the initiator.
This name can be different from the friendly name that was used
for the initiator object. For example:
# iscsitadm modify initiator -H monster620 monster620
- Use the same CHAP secret that was used on the initiator.
For example:
# iscsitadm modify initiator -C monster620
Enter secret: xxxxxx
Re-enter secret: xxxxxx
- Associate the initiator object with one or more targets.
For example:
# iscsitadm modify target -l monster620 sandbox
Using a Third-Party Radius Server to Simplify CHAP Management in Your iSCSI Configuration
You can use a third-party RADIUS server to simplify CHAP secret management. A
RADIUS server is a centralized authentication service. While you must still specify the
initiator's CHAP secret, you are no longer required to specify each target's CHAP
secret on each initiator when using bidirectional authentication with a RADIUS server.
For more information, see:
How to Configure RADIUS for Your iSCSI Configuration
- Become superuser.
- Configure the initiator node with the IP address and port (the default port
is 1812) of the RADIUS server.
For example:
# iscsiadm modify initiator-node --radius-server 10.0.0.72:1812
- Configure the initiator node with the shared secret of the RADIUS server.
# iscsiadm modify initiator-node --radius-shared-secret
Note - The Solaris iSCSI implementation requires that the RADIUS server is configured with a
shared secret before the Solaris iSCSI software can interact with the RADIUS server.
- Enable the RADIUS server.
# iscsiadm modify initiator-node --radius-access enable
Solaris iSCSI and RADIUS Server Error Messages
This section describes the messages that are related to a Solaris iSCSI and
RADIUS server configuration with potential solutions for recovery.
empty RADIUS shared secret
Cause:
The RADIUS server is enabled on the initiator but the RADIUS shared secret
is not set.
Solution:
Configure the initiator with RADIUS shared secret. For more information, see How to Configure RADIUS for Your iSCSI Configuration.
WARNING: RADIUS packet authentication failed
Cause:
The initiator failed to authenticate the RADIUS data packet. This error can occur
if the shared secret configured on the initiator-node is different from the shared
secret on the RADIUS server.
Solution:
Reconfigure the initiator with the correct RADIUS shared secret. For more information, see
How to Configure RADIUS for Your iSCSI Configuration.
How to Configure iSCSI Target Discovery
This procedure assumes that you are logged in to the local system
where you want to configure access to an iSCSI target device.
- Become superuser.
- Configure the target device to be discovered dynamically or statically:
Configure the device dynamically discovered (SendTargets).
For example:
# iscsiadm add discovery-address 10.0.0.1:3260
The iSCSI connection is not initiated until the discovery method is enabled. See the next step.
Configure the device dynamically discovered (iSNS).
For example:
# iscsiadm add iSNS-server 10.0.0.1:3205
The iSCSI connection is not initiated until the discovery method is enabled. See the next step.
Configure the device statically discovered.
For example:
# iscsiadm add static-config eui.5000ABCD78945E2B,10.0.0.1
The iSCSI connection is not initiated until the discovery method is enabled. See the next step.
- Enable the iSCSI target discovery method using one of the following:
If you have configured a dynamically discovered (SendTargets) device, enable the SendTargets discovery method.
# iscsiadm modify discovery --sendtargets enable
If you have configured a dynamically discovered (iSNS) device, enable the iSNS discovery method.
# iscsiadm modify discovery --iSNS enable
If you have configured static targets, enable the static target discovery method.
# iscsiadm modify discovery --static enable
- Create the iSCSI device links for the local system.
# devfsadm -i iscsi
How to Remove Discovered iSCSI Targets
This optional procedure assumes that you are logged in to the local system
where access to an iSCSI target device has already been configured.
After removing a discovery address, iSNS server, static-config, or disabling a discovery method,
the associated targets are logged out. If these associated targets are still
in use, for example, have mounted file systems, the logout of these devices
will fail and they will remain on the active target list.
- Become superuser.
- (Optional) Disable an iSCSI target discovery method using one of the following:
If you need to disable the SendTargets method of discovery, use the following command:
# iscsiadm modify discovery --sendtargets disable
If you need to disable the iSNS method of discovery, use the following command:
# iscsiadm modify discovery --iSNS disable
If you need to disable the static targets, use the following command:
# iscsiadm modify discovery --static disable
- Remove an iSCSI device discovery entry:
Remove an iSCSI SendTargets discovery entry.
For example:
# iscsiadm remove discovery-address 10.0.0.1:3260
Remove an iSCSI iSNS discovery entry.
For example:
# iscsiadm remove isns-server 10.0.0.1:3205
Remove a static iSCSI initiator entry.
For example:
# iscsiadm remove static-config eui.5000ABCD78945E2B,10.0.0.1
Note - If you attempt to disable or remove discovery information that has an associated
logical unit in use, the disable or remove operation fails with the following
message:
logical unit in use
If this occurs, stop all associated I/O on the logical unit, unmount the
file systems, and so on. Then, repeat the disable or remove
operation.
- Remove the iSCSI target device.
Remove a target by specifying the logical unit number (LUN). If you
did not specify a LUN when the target was created, a value of
0 was used. LUN 0 must be the last one removed if
there are multiple LUNs associated with a target.
For example:
# iscsitadm delete target --lun 0 sandbox
Accessing iSCSI Disks
If you want to make the iSCSI drive available on reboot, create
the file system, and add an entry to the /etc/vfstab file as you would
with a UFS file system on a SCSI device.
After the devices have been discovered by the Solaris iSCSI initiator, the login
negotiation occurs automatically. The Solaris iSCSI driver determines the number of LUNs available
and creates the device nodes. Then, the iSCSI devices can be treated as
any other SCSI device.
You can view the iSCSI disks on the local system with the
format utility.
In the following format output, disks 2 and 3 are iSCSI LUNs that
are not under MPxIO control. Disks 21 and 22 are iSCSI LUNs under
MPxIO control.
# format
AVAILABLE DISK SELECTIONS:
0. c0t1d0 <SUN72G cyl 14087 alt 2 hd 24 sec 424>
/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w500000e010685cf1,0
1. c0t2d0 <SUN72G cyl 14087 alt 2 hd 24 sec 424>
/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w500000e0106e3ba1,0
2. c3t0d0 <ABCSTORAGE-100E-00-2.2 cyl 20813 alt 2 hd 16 sec 63>
/iscsi/[email protected]%3A6-8a0900-477d70401-
b0fff044352423a2-hostname-020000,0
3. c3t1d0 <ABCSTORAGE-100E-00-2.2 cyl 20813 alt 2 hd 16 sec 63>
/iscsi/[email protected]%3A6-8a0900-3fcd70401
-085ff04434f423a2-hostname-010000,0
.
.
.
21. c4t60A98000686F694B2F59775733426B77d0 <ABCSTORAGE-LUN-0.2 cyl
4606 alt 2 hd 16 sec 256>
/scsi_vhci/ssd@g60a98000686f694b2f59775733426b77
22. c4t60A98000686F694B2F59775733434C41d0 <ABCSTORAGE-LUN-0.2 cyl
4606 alt 2 hd 16 sec 256>
/scsi_vhci/ssd@g60a98000686f694b2f59775733434c41
Monitoring Your iSCSI Configuration
You can display information about the iSCSI initiator and target devices by using
the iscsiadm list command.
- Become superuser.
- Display information about the iSCSI initiator.
For example:
# iscsiadm list initiator-node
Initiator node name: iqn.1986-03.com.sun:01:0003ba4d233b.425c293c
Initiator node alias: zzr1200
Login Parameters (Default/Configured):
Header Digest: NONE/-
Data Digest: NONE/-
Authentication Type: NONE
RADIUS Server: NONE
RADIUS access: unknown
Configured Sessions: 1
- Display information about which discovery methods are in use.
For example:
# iscsiadm list discovery
Discovery:
Static: enabled
Send Targets: enabled
iSNS: enabled
Example 14-1 Listing iSCSI Target Information
The following example shows how to list the parameter settings for a specific
iSCSI target.
# iscsiadm list target-param iqn.1992-08.com.abcstorage:sn.33592219
Target: iqn.1992-08.com.abcstorage:sn.33592219The iscsiadm list target-param -v command displays the following information:
The authentication settings for the target
The default settings for the target login parameters
The configured value for each login parameter
The iscsiadm list target-param -v command displays the default parameter value before the / designator and the
configured parameter value after the / designator. If you have not configured
any parameters, the configured parameter value displays as a hyphen (-). For more
information, see the following examples.
# iscsiadm list target-param -v eui.50060e8004275511 Target: eui.50060e8004275511
Alias: -
Bi-directional Authentication: disabled
Authentication Type: NONE
Login Parameters (Default/Configured):
Data Sequence In Order: yes/-
Data PDU In Order: yes/-
Default Time To Retain: 20/-
Default Time To Wait: 2/-
Error Recovery Level: 0/-
First Burst Length: 65536/-
Immediate Data: yes/-
Initial Ready To Transfer (R2T): yes/-
Max Burst Length: 262144/-
Max Outstanding R2T: 1/-
Max Receive Data Segment Length: 65536/-
Max Connections: 1/-
Header Digest: NONE/-
Data Digest: NONE/-
Configured Sessions: 1The following example iscsiadm list target-param -v output displays the parameters that were negotiated between the
target and the initiator.
# iscsiadm list target -v eui.50060e8004275511
Target: eui.50060e8004275511
TPGT: 1
ISID: 4000002a0000
Connections: 1
CID: 0
IP address (Local): 172.90.101.71:32813
IP address (Peer): 172.90.101.40:3260
Discovery Method: Static
Login Parameters (Negotiated):
Data Sequence In Order: yes
Data PDU In Order: yes
Default Time To Retain: 0
Default Time To Wait: 3
Error Recovery Level: 0
First Burst Length: 65536
Immediate Data: yes
Initial Ready To Transfer (R2T): yes
Max Burst Length: 262144
Max Outstanding R2T: 1
Max Receive Data Segment Length: 65536
Max Connections: 1
Header Digest: NONE
Data Digest: NONE
Modifying iSCSI Initiator and Target Parameters
You can modify parameters on both the iSCSI initiator and the iSCSI target
device. However, the only parameters that can be modified on the iSCSI initiator
are the following:
iSCSI initiator node name - You can change the initiator node name to a different name. If you change the initiator node name, the targets that were discovered by iSNS might be removed from the initiator's target list, depending on the discovery domain configuration on the iSNS server at the time when the name was changed. For more information, see How to Modify iSCSI Initiator and Target Parameters.
Header digest – The value can be none, the default value, or CRC32.
Data digest – The value can be none, the default value, or CRC32.
Authentication and CHAP secret – For more information about setting up authentication, see How to Configure CHAP Authentication for Your iSCSI Initiator.
Configured sessions – For more information about configuring multiple sessions, see How to Enable Multiple iSCSI Sessions for a Target.
The iSCSI driver provides default values for the iSCSI initiator and iSCSI target
device parameters. If you modify the parameters of the iSCSI initiator, the modified
parameters are inherited by the iSCSI target device, unless the iSCSI target device
is already set to a different value.
Caution - Ensure that the target software supports the parameter to be modified. Otherwise, you
might be unable to log in to the iSCSI target device. See your
array documentation for a list of supported parameters.
Modifying iSCSI parameters should be done when I/O between the initiator and the
target is complete. The iSCSI driver reconnects the session after the changes are
made with the iscsiadm modify command.
How to Modify iSCSI Initiator and Target Parameters
The first part of this procedure illustrates how modifying parameters of the iSCSI
initiator are inherited by the iSCSI target device. The second part of this
procedure shows how to actually modify parameters on the iSCSI target device.
- Become superuser.
- List the current parameters of the iSCSI initiator and target device.
- List the current parameters of the iSCSI initiator. For example:
# iscsiadm list initiator-node
Initiator node name: iqn.1986-03.com.sun:01:0003ba4d233b.425c293c
Initiator node alias: zzr1200
Login Parameters (Default/Configured):
Header Digest: NONE/-
Data Digest: NONE/-
Authentication Type: NONE
RADIUS Server: NONE
RADIUS access: unknown
Configured Sessions: 1
- List the current parameters of the iSCSI target device. For example:
# iscsiadm list target-param -v iqn.1992-08.com.abcstorage:sn.84186266
Target: iqn.1992-08.com.abcstorage:sn.84186266
Alias: -
Bi-directional Authentication: disabled
Authentication Type: NONE
Login Parameters (Default/Configured):
Data Sequence In Order: yes/-
Data PDU In Order: yes/-
Default Time To Retain: 20/-
Default Time To Wait: 2/-
Error Recovery Level: 0/-
First Burst Length: 65536/-
Immediate Data: yes/-
Initial Ready To Transfer (R2T): yes/-
Max Burst Length: 262144/-
Max Outstanding R2T: 1/-
Max Receive Data Segment Length: 65536/-
Max Connections: 1/-
Header Digest: NONE/-
Data Digest: NONE/-
Configured Sessions: 1Note that both header digest and data digest parameters are currently set to
NONE for both the iSCSI initiator and the iSCSI target device.
To review the default parameters of the iSCSI target device, see the
iscsiadm list target-param output in Example 14-1.
- Modify the parameter of the iSCSI initiator.
For example, set header digest to CRC32.
# iscsiadm modify initiator-node -h CRC32
If you change the initiator node name, the targets that were discovered by
iSNS might be logged out and removed from the initiator's target list, if
the new name does not belong to the same discovery domain as
that of the targets. If, however, the targets are in use and busy,
they are not removed. For example, if a file is opened or
a file system is mounted on these targets.
You may also see new targets after the name change if these
targets and the new initiator node name belong to the same discovery domain.
- Verify that the parameter was modified.
- Display the updated parameter information for the iSCSI initiator. For example:
# iscsiadm list initiator-node
Initiator node name: iqn.1986-03.com.sun:01:0003ba4d233b.425c293c
Initiator node alias: zzr1200
Login Parameters (Default/Configured):
Header Digest: NONE/CRC32
Data Digest: NONE/-
Authentication Type: NONE
RADIUS Server: NONE
RADIUS access: unknown
Configured Sessions: 1Note that the header digest is now set to CRC32.
- Display the updated parameter information for the iSCSI target device. For example:
# iscsiadm list target-param -v iqn.1992-08.com.abcstorage:sn.84186266
Target: iqn.1992-08.com.abcstorage:sn.84186266
Alias: -
Bi-directional Authentication: disabled
Authentication Type: NONE
Login Parameters (Default/Configured):
Data Sequence In Order: yes/-
Data PDU In Order: yes/-
Default Time To Retain: 20/-
Default Time To Wait: 2/-
Error Recovery Level: 0/-
First Burst Length: 65536/-
Immediate Data: yes/-
Initial Ready To Transfer (R2T): yes/-
Max Burst Length: 262144/-
Max Outstanding R2T: 1/-
Max Receive Data Segment Length: 65536/-
Max Connections: 1/-
Header Digest: CRC32/-
Data Digest: NONE/-
Configured Sessions: 1Note that the header digest is now set to CRC32.
- Verify that the iSCSI initiator has reconnected to the iSCSI target. For example:
# iscsiadm list target -v iqn.1992-08.com.abcstorage:sn.84186266
Target: iqn.1992-08.com.abcstorage:sn.84186266
TPGT: 2
ISID: 4000002a0000
Connections: 1
CID: 0
IP address (Local): nnn.nn.nn.nnn:64369
IP address (Peer): nnn.nn.nn.nnn:3260
Discovery Method: SendTargets
Login Parameters (Negotiated):
.
.
.
Header Digest: CRC32
Data Digest: NONE
- Unset an iSCSI initiator parameter or an iSCSI target device parameter.
You can unset a parameter by setting it back to it's default setting
with the iscsiadm modify command. Or, you can use the iscsiadm remove command to reset
all target properties to the default settings.
The iscsiadm modify target-param command changes only the parameters that are specified on the command
line.
The following example shows how to reset the header digest to none:
# iscsiadm modify target-param -h none iqn.1992-08.com.abcstorage:sn...
For information about using the iscsiadm remove target-param command, see iscsiadm(1M).
Setting Up Solaris iSCSI Multipathed Devices
Keep the following guidelines in mind when you consider using Solaris iSCSI multipathed
(MPxIO) devices:
Solaris iSCSI and MPXIO: MPxIO supports target port aggregation and availability in Solaris iSCSI configurations that configure multiple sessions per target (MS/T) on the iSCSI initiator.
IPMP should be used for aggregation and failover of two or more NICs.
A basic configuration for an iSCSI host would be a server with two NICs that are dedicated to iSCSI traffic. The NICs should be configured by using IPMP. Additional NICs should be provided for non-iSCSI traffic to optimize performance.
Active multipathing can only be achieved by using the Solaris iSCSI MS/T feature or the TPGT feature (?) and the failover and redundancy of an IPMP configuration:
If one NIC fails in an IPMP configuration, IPMP handles the failover. The MPxIO driver does not notice the failure. In a non-IPMP configuration, the MPxIO driver fails and offlines the path.
If one target port fails in an IPMP configuration, the MPxIO driver notices the failure and provides the failover. In a non-IPMP configuration, the MPXIO driver notices the failure and provides the failover.
For more information about using the Solaris iSCSI MS/T feature with IPMP and multipathing, see SunSolve Infodoc 88246, Understanding an iSCSI MS/T multi-path configuration.
For information about configuring multiple sessions per target, see How to Enable Multiple iSCSI Sessions for a Target. For information about configuring IPMP, see Part IV, IPMP, in System Administration Guide: IP Services.
Solaris iSCSI and FC and MPXIO: The MPxIO driver provides the following behavior in more complex iSCSI/FC configurations:
If you have dual iSCSI to FC bridges in a FC SAN, iSCSI presents target paths to MPxIO and MPxIO matches the unique SCSI per LUN identifier, and if they are identical, presents one path to the iSCSI driver.
If you have a configuration that connects a target by using both iSCSI and FC, the MPxIO driver can provide different transports to the same device. In this configuration, MPxIO utilizes both paths.
If you are using iSCSI and FC in combination with MPxIO, make sure that the MPxIO settings in the /kernel/drv/fp.conf file and the /kernel/drv/iscsi.conf match the MPxIO configuration that you want supported. For example, in the fp.conf, you can determine whether MPxIO is enabled globally on the HBA or on a per-port basis.
Third-Party Hardware Considerations: Find out if your third-party HBA is qualified to work with Solaris iSCSI and MPxIO.
If you are using a third-party HBA, you might need to ask your third-party HBA vendor for the symmetric-option information for the /kernel/drv/scsi_vhci.conf file.
How to Enable Multiple iSCSI Sessions for a Target
This procedure can be used to create multiple iSCSI sessions that connect to
a single target. This scenario is useful with iSCSI target devices that support
login redirection or have multiple target portals in the same target portal group.
iSCSI multiple sessions per target support should be used in combination with
Solaris SCSI Multipathing (MPxIO). You can also get higher bandwidth if you utilize
multiple NICs on the host side to connect to multiple portals on the
same target.
The MS/T feature creates two or more sessions on the target by
varying the initiator's session ID (ISID). Enabling this feature creates two SCSI layer paths
on the network so that multiple targets are exposed up through the iSCSI
layer to the Solaris I/O layer. The MPxIO driver handles the reservations across
these paths.
Review the following items before configuring multiple sessions for an iSCSI target:
A typical MS/T configuration has 2 or more configured-sessions.
However, if your storage supports multiple TPGTs and if you are using SendTarget discovery on your host system, then the number of configured sessions can be set to 1. SendTarget discovery automatically knows the existence of multiple paths and multiple target sessions are created.
Confirm that the mxpio configuration parameter is enabled in the /kernel/drv/iscsi.conf file.
# cd /kernel/drive
# grep mpxio iscsi.conf
iscsi.conf:mpxio-disable="no";
Confirm that the multiple network connections are configured by using IPMP.
Confirm that the multiple network connections are available
# ifconfig -a
For more information about how iSCSI interacts with MPxIO paths, see Setting Up Solaris iSCSI Multipathed Devices
- Become superuser.
- List the current parameters for the iSCSI initiator and target.
- List the current parameters for the iSCSI initiator. For example:
# iscsiadm list initiator-node
Initiator node name: iqn.1986-03.com.sun:01:0003ba4d233b.425c293c
Initiator node alias: zzr1200
.
.
.
Configured Sessions: 1
- List the current parameters of the iSCSI target device. For example:
# iscsiadm list target-param -v iqn.1992-08.com.abcstorage:sn.84186266
Target: iqn.1992-08.com.abcstorage:sn.84186266
Alias: -
.
.
.
Configured Sessions: 1The configured sessions value is the number of configured iSCSI sessions that will
be created for each target name in a target portal group.
- Select one of the following to modify the number of configured sessions at
either the initiator node, to apply to all targets, at a target level,
or to apply to a specific target.
The number of sessions for a target must be between 1 and 4.
Apply the parameter to the iSCSI initiator node.
For example:
# iscsiadm modify initiator-node -c 2
Apply the parameter to the iSCSI target.
For example:
# iscsiadm modify target-param -c 2 iqn.1992-08.com.abcstorage:sn.84186266
Configured sessions can also be bound to a specific local IP address. Using
this method, one or more local IP addresses are supplied in a
comma-separated list. Each IP address represents an iSCSI session. This method can
also be done at the initiator-node or target-param level. For example:
# iscsiadm modify initiator-node -c 10.0.0.1,10.0.0.2
Note - If the specified IP address is not routable, the address is ignored and
the default Solaris route and IP address is used for this session.
- Verify that the parameter was modified.
- Display the updated information for the initiator node. For example:
# iscsiadm list initiator-node
Initiator node name: iqn.1986-03.com.sun:01:0003ba4d233b.425c293c
Initiator node alias: zzr1200
.
.
.
Configured Sessions: 2
- Display the updated information for the target node. For example:
# iscsiadm list target-param -v iqn.1992-08.com.abcstorage:sn.84186266
Target: iqn.1992-08.com.abcstorage:sn.84186266
Alias: -
.
.
.
Configured Sessions: 2
- List the multiple paths with the mpathadm list lu command to confirm that the OS
device name matches the iscsiadm list output and that the path count is 2
or more.