Storage Admin HubConfiguration · Protection · Recovery
All guides/SAN
SAN · ONTAP 9

Provision an iSCSI LUN

Target LIFs, initiator, igroup, LUN, mapping, multipath.

Scenario

Example: one Linux host with initiator IQN iqn.1993-08.org.debian:01:labhost gets a 500 GiB test LUN. Use host-specific NetApp interoperability guidance for the actual OS.

Before you change production

Commands and screens can differ by release and platform. Replace example names and documentation IP addresses. Check prerequisites, impact, current health and rollback with your change owner.

1. Design paths

  1. Confirm the host, ONTAP, switch and multipath combination in the interoperability matrix. Enable iSCSI on the SVM and create target LIFs on appropriate nodes and fabrics.
  2. Record host initiator IQN, intended target portal IPs, VLAN, MTU, authentication if required, and the host OS type for the LUN. Avoid a single network path.
Read-only checks 
vserver iscsi show
network interface show
lun show

2. Provision and map

  1. In System Manager, create a LUN on the correct SVM with the host OS type, size, and volume placement. Create an igroup for only the approved initiator(s).
  2. Map the LUN to that igroup. Review the resulting LUN ID and reporting nodes. ONTAP Selective LUN Map normally advertises paths through the owner and HA partner; do not manually add reporting nodes without a reason.
  3. On the host, discover target portals, log in, rescan the SCSI bus, and configure the supported multipath package. Verify path count and LUN serial before formatting.
Read-only validation 
lun show
lun mapping show
network interface show

Worked CLI example: one Linux test LUN

  1. Assume the SVM already has iSCSI service and redundant target LIFs, and a suitable volume vol_san exists. Confirm the host OS type and initiator IQN from the actual host.
  2. Create the LUN, a host-specific igroup and the mapping. On the host, rescan and verify serial and multipath before creating a file system.
Example change commands · review before running 
vserver iscsi show -vserver svm_prod
network interface show -vserver svm_prod
lun create -vserver svm_prod -volume vol_san -lun lun_lab -size 500GB -ostype linux -space-reserve disabled
igroup create -vserver svm_prod -igroup ig_lab -protocol iscsi -ostype linux -initiator iqn.1993-08.org.debian:01:labhost
lun mapping create -vserver svm_prod -volume vol_san -lun lun_lab -igroup ig_lab
lun mapping show -vserver svm_prod
Verify

The LUN is mapped only to ig_lab and the host discovers the expected serial through redundant paths.

3. Test safely

  1. Test failover of a network path during an approved window and confirm I/O continues through another path. Monitor ONTAP and host logs for path recovery.
  2. If no device appears, test portal connectivity, initiator login, IQN in the igroup, mapping, LUN online status, and host rescan in that order. Never format a device until its identity is confirmed.
Verify

Host sees exactly the intended LUN and supported path count, with no duplicate or unexpected devices.

If validation fails

  1. If discovery finds no target, check TCP connectivity and iSCSI service first, then portal IP and initiator configuration. Verify the host is on the planned VLAN.
  2. If login works but the LUN is absent, compare IQN in the igroup, LUN mapping and host rescan. Record the target and LUN serial before any disk operation.
  3. If one path fails, preserve the surviving path and check its separate NIC, switch and target LIF; do not disable multipath to make the device appear.
Verify

Re-run the original validation and record the observed result, exact error, time, and corrective action.

NetApp references