Skip Navigation Links | |
Exit Print View | |
Oracle Solaris SAN Configuration and Multipathing Guide Oracle Solaris 10 1/13 Information Library |
1. Solaris I/0 Multipathing Overview
2. Configuring Solaris I/O Multipathing Features
3. Configuring Fabric-Connected Devices
4. Configuring Oracle Solaris iSCSI Initiators
Oracle Solaris iSCSI Technology (Overview)
Identifying Solaris iSCSI Software and Hardware Requirements
Oracle Solaris iSCSI Terminology
Recommended iSCSI Configuration Practices
Configuring Solaris iSCSI Initiators
Configuring Dynamic or Static Target Discovery
How to Configure an iSCSI Initiator and Target Discovery
How to Access iSCSI Disks Upon Reboot
How to Remove Discovered iSCSI Targets
Configuring Authentication in Your iSCSI-Based Storage Network
How to Configure CHAP Authentication for Your iSCSI Initiator
How to Configure CHAP Authentication for Your iSCSI Target
Using a Third-Party RADIUS Server to Simplify CHAP Management in Your iSCSI Configuration
Oracle Solaris iSCSI and RADIUS Server Error Messages
Setting Up Solaris iSCSI Multipathed Devices
How to Enable Multiple iSCSI Sessions for a Target
Monitoring Your iSCSI Configuration
Troubleshooting iSCSI Configuration Problems
No Connections to the iSCSI Target From the Local System
How to Troubleshoot iSCSI Connection Problems
iSCSI Device or Disk Is Not Available on the Local System
How to Troubleshoot iSCSI Device or Disk Unavailability
Use LUN Masking When Using the iSNS Discovery Method
6. Configuring IPFC SAN Devices
7. Booting the Oracle Solaris OS From Fibre Channel Devices on x86 Based Systems
8. Persistent Binding for Tape Devices
A. Manual Configuration for Fabric-Connected Devices
This is a general list of tasks associated with configuring Solaris iSCSI initiators. Some of the tasks are optional depending on your network configuration needs. Some of the links below will take you to separate documents that describe network configuration and initiator configuration.
Identifying Solaris iSCSI Software and Hardware Requirements
Oracle Solaris Administration: Network Interfaces and Network Virtualization
Configuring Authentication in Your iSCSI-Based Storage Network
Determine whether you want to configure one of the dynamic device discovery methods or use static iSCSI initiator targets to perform device discovery.
Dynamic device discovery – If an iSCSI node exposes many 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 device discovery.
Two dynamic device discovery methods are available:
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 information as possible. It also provides state change notification to notify the iSCSI initiator when changes in the operational state of storage nodes occur. To use the iSNS discovery method, 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 the 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.
Static device discovery – If an iSCSI node has few 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 the initiator is communicating with the iSCSI target device.
Part of the initiator configuration process is to identify the iSCSI target discovery method, which presents an initiator with a list of available targets. You can configure iSCSI targets for static, SendTargets, or iSNS dynamic discovery. Dynamic discovery using the SendTargets option is the optimum configuration for an iSCSI initiator that accesses a large number of targets, such over an iSCSI to Fibre Channel bridge. SendTargets dynamic discovery requires the IP address and port combination of the iSCSI target for the iSCSI initiator to perform the target discovery. The most common discovery method is SendTargets.
When configuring the target discovery method, you must provide the following information, depending on which method you choose:
SendTargets – Target IP address
iSNS – iSNS server address
Static – Target IP address and target name
For more information about configuring target discovery methods, see Configuring Dynamic or Static Target Discovery.
target# ifconfig -a lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 1.2.3.4 netmask ffffff00 broadcast 1.2.3.4 ether 0:3:ba:64:cb:1f target# iscsitadm list target -v sanbox Target: sanbox iSCSI Name: iqn.1986-03.com.sun:02:62d527ac-076d-ea1b-ff4f-cbfca3b12345.sanbox Connections: 0 ACL list: TPGT list: LUN information: LUN: 0 GUID: 600144f05059f7dd000003ba64ca1b00 VID: SUN PID: SOLARIS Type: disk Size: 2.0G Status: unknown
initiator# iscsiadm add static-config iqn.1986-03.com.sun:02:62d527ac-076d-ea1b-ff4f-cbfca3b12345.sanbox, 1.2.3.4
initiator# iscsiadm list static-config
The iSCSI connection is not initiated until the discovery method is enabled. See the next step.
If you have configured a dynamically discovered (SendTargets) target, configure the SendTargets discovery method.
initiator# iscsiadm add discovery-address 1.2.3.4
If you have configured a dynamically discovered (iSNS) target, configure the iSNS discovery method.
initiator# iscsiadm add isns-server 1.2.3.4
If you have configured a dynamically discovered (SendTargets) target, enable the SendTargets discovery method.
initiator# iscsiadm modify discovery --sendtargets enable
If you have configured a dynamically discovered (iSNS) target, enable the iSNS discovery method.
initiator# iscsiadm modify discovery --iSNS enable
If you have configured static targets, enable the static target discovery method.
initiator# iscsiadm modify discovery --static enable
initiator# devfsadm -i iscsi
If you want to access the iSCSI disks upon reboot, create the file system on the disk, and add an /etc/vfstab entry as you would with a UFS file system on a SCSI device. Then, create a new SMF service for mounting iSCSI disks that depends on the iSCSI initiator service. For more information, see How to Access iSCSI Disks Upon Reboot.
After the devices have been discovered by the Solaris iSCSI initiator, the login negotiation occurs automatically. The Solaris iSCSI driver determines the number of available LUNs 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 by using 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.
initiator# 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/disk@0000iqn.2001-05.com.abcstorage%3A6-8a0900-477d70401- b0fff044352423a2-hostname-020000,0 3. c3t1d0 <ABCSTORAGE-100E-00-2.2 cyl 20813 alt 2 hd 16 sec 63> /iscsi/disk@0000iqn.2001-05.com.abcstorage%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
Follow the steps below to access iSCSI disks after the system is rebooted.
initiator# vi /etc/vfstab #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # /dev/dsk/c3t600144F04B555F370000093D00495B00d0s0 - /mnt ufs - no -
After removing a discovery address, iSNS server, or static configuration, or after disabling a discovery method, the associated targets are logged out. If these associated targets are still in use, for example, they have mounted file systems, the logout of these devices will fail, and they will remain on the active target list.
This optional procedure assumes that you are logged in to the local system where access to an iSCSI target device has already been configured.
If you need to disable the SendTargets discovery method, use the following command:
initiator# iscsiadm modify discovery --sendtargets disable
If you need to disable the iSNS discovery method, use the following command:
initiator# iscsiadm modify discovery --iSNS disable
If you need to disable the static target discovery method, use the following command:
initiator# iscsiadm modify discovery --static disable
Remove an iSCSI SendTargets discovery entry.
For example:
initiator# 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 discovery entry.
For example:
initiator# iscsiadm remove static-config iqn.1986-03.com.sun:02:62d527ac-076d-ea1b-ff4f-cbfca3b12345.sanpool, 1.2.3.4:3260
Note - If you attempt to disable or remove a discovery entry that has an associated logical unit in use, the disable or remove operation fails with the following message:
logical unit in use
If this errors 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 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 LUN removed if multiple LUNs are associated with a target.
For example:
initiator# iscsitadm delete target --lun 0 sandbox
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 as follows:
Unidirectional authentication enables the target to authenticate the identity of the initiator. Unidirectional authentication is done on behalf of the target to authenticate the initiator.
Bidirectional authentication adds a second level of security by enabling the initiator to authenticate the identity of the target. Bidirectional authentication is driven from the initiator, which controls whether bidirectional authentication is performed. The only setup required for the target is that the chap user and chap secret must be correctly defined.
This procedure assumes that you are logged in to the local system where you want to securely access the configured iSCSI target device.
The length of the CHAP secret key for the COMSTAR iSCSI target must be a minimum of 12 characters and a maximum of 255 characters. Some initiators support only a shorter maximum length for the secret key.
Each node identifying itself using CHAP must have both a user name and a password. In the Oracle Solaris OS, the CHAP user name is set to the initiator or target node name (that is, the iqn name) by default. The CHAP user name can be set to any length of text that is less than 512 bytes. The 512-byte length limit is an Oracle Solaris limitation. However, if you do not set the CHAP user name, it is set to the node name upon initialization.
You can simplify CHAP secret key management by using a third-party RADIUS server, which acts as a centralized authentication service. When you use RADIUS, the RADIUS server stores the set of node names and matching CHAP secret keys. The system performing the authentication forwards the node name of the requester and the supplied secret of the requester to the RADIUS server. The RADIUS server confirms whether the secret key is the appropriate key to authenticate the given node name. Both iSCSI and iSER support the use of a RADIUS server.
For more information about using a third-party RADIUS server, see Using a Third-Party RADIUS Server to Simplify CHAP Management in Your iSCSI Configuration.
Unidirectional authentication, the default method, enables the target to validate the initiator. Complete steps 3–5 only.
Bidirectional authentication adds a second level of security by enabling the initiator to authenticate the target. Complete steps 3–9.
The following command initiates a dialogue to define the CHAP secret key:
initiator# iscsiadm modify initiator-node --CHAP-secret Enter CHAP secret: ************ Re-enter secret: ************
By default, the initiator's CHAP user name is set to the initiator node name.
Use the following command to use your own initiator CHAP user name:
initiator# iscsiadm modify initiator-node --CHAP-name new-CHAP-name
initiator# iscsiadm modify initiator-node --authentication CHAP
CHAP requires that the initiator node have both a user name and a password. The user name is typically used by the target to look up the secret key for the given user name.
Enable bidirectional CHAP for connections with the target.
initiator# iscsiadm modify target-param -B enable target-iqn
Disable bidirectional CHAP.
initiator# iscsiadm modify target-param -B disable target-iqn
initiator# iscsiadm modify target-param --authentication CHAP target-iqn
The following command initiates a dialogue to define the CHAP secret key:
initiator# iscsiadm modify target-param --CHAP-secret target-iqn
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:
initiator# iscsiadm modify target-param --CHAP-name target-CHAP-name
This procedure assumes that you are logged in to the local system that contains the iSCSI targets.
Unidirectional authentication is the default method. Complete steps 3–5 only.
For bidirectional authentication. Complete steps 3–7.
target# itadm modify-target -a chap target-iqn
Create the initiator context with the initiator's full node name and with the initiator's CHAP secret key.
target# itadm create-initiator -s initiator-iqn Enter CHAP secret: ************ Re-enter secret: ************
target# itadm modify-initiator -u initiator-CHAP-name initiator-iqn
target# itadm modify-target -s target-iqn Enter CHAP secret: ************ Re-enter secret: ************
target# itadm modify-target -u target-CHAP-name target-iqn
You can use a third-party RADIUS server that acts as a centralized authentication service to simplify CHAP key secret management. With this method, the recommended practice is to use the default CHAP name for each initiator node. In the common case when all initiators are using the default CHAP name, you do not have to create initiator contexts on the target.
You can use a third-party RADIUS server that acts as a centralized authentication service to simplify CHAP key secret management. With this method, the recommended practice is to use the default CHAP name for each initiator node. In the common case when all initiators are using the default CHAP name, you do not have to create initiator contexts on the target.
This procedure assumes that you are logged in to the local system where you want to securely access the configured iSCSI target device.
The default port is 1812. This configuration is completed once for all iSCSI targets on the target system.
initiator# itadm modify-defaults -r RADIUS-server-IP-address Enter RADIUS secret: ************ Re-enter secret: ************
initiator# itadm modify-defaults -d Enter RADIUS secret: ************ Re-enter secret: ************
This configuration can be performed for an individual target or as a default for all targets.
initiator# itadm modify-target -a radius target-iqn
The identity of the target node (for example, its IP address)
The shared secret key that the target node uses to communicate with the RADIUS server
The initiator's CHAP name (for example, it's iqn name) and the secret key for each initiator that needs to be authenticated
You can use a third-party RADIUS server that acts as a centralized authentication service to simplify CHAP secret key management. This setup is only useful when the initiator is requesting bidirectional CHAP authentication. You must still specify the initiator's CHAP secret key, but you are not required to specify the CHAP secret key for each target on an initiator when using bidirectional authentication with a RADIUS server. RADIUS can be independently configured on either the initiator or the target. The initiator and the target do not have to use RADIUS.
The default port is 1812.
# iscsiadm modify initiator-node --radius-server ip-address:1812
The RADIUS server must be configured with a shared secret for iSCSI to interact with the server.
# iscsiadm modify initiator-node --radius-shared-secret Enter secret: Re-enter secret
# iscsiadm modify initiator-node --radius-access enable
# iscsiadm modify initiator-node --authentication CHAP # iscsiadm modify target-param --bi-directional-authentication enable target-iqn # iscsiadm modify target-param --authentication CHAP target-iqn
The identity of this node (for example, its IP address)
The shared secret key that this node uses to communicate with the RADIUS server
The target's CHAP name (for example, its iqn name) and the secret key for each target that needs to be authenticated
This section describes the error messages that are related to an Oracle Solaris iSCSI and RADIUS server configuration. Potential solutions for recovery are also provided.
empty RADIUS shared secret
Cause: The RADIUS server is enabled on the initiator, but the RADIUS shared secret key is not set.
Solution: Configure the initiator with the RADIUS shared secret key. For more information, see How to Configure a RADIUS Server for Your iSCSI Target.
WARNING: RADIUS packet authentication failed
Cause: The initiator failed to authenticate the RADIUS data packet. This error can occur if the shared secret key that is configured on the initiator node is different from the shared secret key on the RADIUS server.
Solution: Reconfigure the initiator with the correct RADIUS shared secret. For more information, see How to Configure a RADIUS Server for Your iSCSI Target.
Consider the following guidelines for 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.
Use IPMP for aggregation and failover of two or more NICs.
A basic configuration for an iSCSI host is a server with two NICs that are dedicated to iSCSI traffic. The NICs are configured by using IPMP. Additional NICs are provided for non-iSCSI traffic to optimize performance.
Active multipathing can only be achieved by using the Solaris iSCSI MS/T 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 information about configuring multiple sessions per target, see How to Enable Multiple iSCSI Sessions for a Target. For information about configuring IPMP, see Part V, IPMP, in Oracle Solaris Administration: IP Services.
Solaris iSCSI, Fibre-Channel (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 an FC SAN, iSCSI presents target paths to MPxIO. 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 files match the MPxIO configuration that you want supported. For example, in 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.
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. Use iSCSI multiple sessions per target with Solaris SCSI Multipathing (MPxIO). You can also achieve 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 through the iSCSI layer to the Solaris I/O layer. The MPxIO driver handles the reservations across these paths.
For more information about how iSCSI interacts with MPxIO paths, see Setting Up Solaris iSCSI Multipathed Devices.
Review the following items before configuring multiple sessions for an iSCSI target:
A typical MS/T configuration has two 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 detects 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/drv # 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
initiator# iscsiadm list initiator-node Initiator node name: iqn.1986-03.com.sun:01:0003ba4d233b.425c293c Initiator node alias: zzr1200 . . . Configured Sessions: 1
initiator# iscsiadm list target-param -v iqn.1992-08.com.abcstorage:sn.84186266 Target: iqn.1992-08.com.abcstorage:sn.84186266 Alias: - . . . Configured Sessions: 1
The configured sessions value is the number of configured iSCSI sessions that will be created for each target name in a target portal group.
The number of sessions for a target must be between 1 and 4.
Apply the parameter to the iSCSI initiator node.
For example:
initiator# iscsiadm modify initiator-node -c 2
Apply the parameter to the iSCSI target.
For example:
initiator# iscsiadm modify target-param -c 2 iqn.1992-08.com.abcstorage:sn.84186266
Bind configured sessions to one or more local IP addresses.
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:
initiator# 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.
initiator# iscsiadm list initiator-node Initiator node name: iqn.1986-03.com.sun:01:0003ba4d233b.425c293c Initiator node alias: zzr1200 . . . Configured Sessions: 2
initiator# iscsiadm list target-param -v iqn.1992-08.com.abcstorage:sn.84186266 Target: iqn.1992-08.com.abcstorage:sn.84186266 Alias: - . . . Configured Sessions: 2
You can display information about the iSCSI initiator and target devices by using the iscsiadm list command.
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
For example:
# iscsiadm list discovery Discovery: Static: enabled Send Targets: enabled iSNS: enabled
Example 4-1 Displaying iSCSI Target Information
The following example shows how to display 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.33592219
The 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: 1
The following example 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
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 Modifying iSCSI Initiator and Target Parameters.
Header digest – NONE, the default value or CRC32.
Data digest – NONE, the default value or CRC32.
Authentication and CHAP secret – For more information about setting up authentication, see How to Configure a RADIUS Server 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 already has different values.
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 by using the iscsiadm modify command.
The first part of this procedure illustrates how modified 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.
This optional procedure assumes that you are logged in to the local system where access to an iSCSI target device has already been configured.
initiator# 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
initiator# 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: 1
Note 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 4-1.
For example, set the header digest to CRC32.
initiator# 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. However, if the targets are in use, they are not removed. For example, if a file is open or a file system is mounted on these targets, the targets will not removed.
You might also see new targets after the name change if these targets and the new initiator node name belong to the same discovery domain.
initiator# 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: 1
Note that the header digest is now set to CRC32.
initiator# 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: 1
Note that the header digest is now set to CRC32.
initiator# 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
You can unset a parameter by setting it back to its default setting by using 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:
initiator# iscsiadm modify target-param -h none iqn.1992-08.com.abcstorage:sn...
For information about the iscsiadm remove target-param command, see iscsiadm(1M).