AFF/FAS SCSI FC · ESXi example · two independent fabrics; ASA/ASA r2 behavior differs
Illustrative design: ESX01 has one HBA port in Fabric A and one in Fabric B. Each fabric reaches one FC target LIF on each controller of the HA pair. ESX01 receives a new 100 GB disposable test LUN. This is SCSI FC, not NVMe/FC; confirm the host release, adapter, firmware and multipath policy in NetApp interoperability guidance.
About the command and output examples
Names, addresses and results are illustrative. Commands have not been executed against a live storage system or SAN switch for this publication. Confirm syntax and compatibility for your release, then rehearse in an approved lab. Existing-data recovery and destructive changes need an environment-specific plan. Read the editorial standards.
01Draw the paths and collect actual WWPNs
The host initiator WWPN, the target LIF WWPN and the LUN serial identify different things. Zoning allows an initiator to contact a target; an igroup and LUN mapping authorize the device presentation after that contact. Both are required. Record real WWPNs from discovery rather than using an alias copied from an old change ticket.
| Fabric | Initiator alias | Target aliases | Planned paths |
|---|---|---|---|
| A | ESX01_HBA_A | N1_FC_A, N2_FC_A | ESX01 HBA A to both reporting nodes |
| B | ESX01_HBA_B | N1_FC_B, N2_FC_B | ESX01 HBA B to both reporting nodes |
- Verify HBA drivers, firmware, switch and ONTAP combinations. Inspect both host adapters and both switch fabrics. Confirm links and fabric login before changing zones.
- List target FC LIFs and their WWPNs on ONTAP. Identify which target is on each node and fabric. SAN LIF failover behavior differs by platform and release; do not apply a NAS LIF migration plan to this FC design.
vserver fcp show -vserver svm_san
network interface show -vserver svm_san
network interface show -vserver svm_san -fields address,home-node,home-port,status-oper
# ESXi read-only adapter discovery
esxcli storage core adapter list02Create the zoning change as a reviewed matrix
| Zone | Members | Fabric |
|---|---|---|
| Z_ESX01_A_N1 | ESX01_HBA_A + N1_FC_A | A |
| Z_ESX01_A_N2 | ESX01_HBA_A + N2_FC_A | A |
| Z_ESX01_B_N1 | ESX01_HBA_B + N1_FC_B | B |
| Z_ESX01_B_N2 | ESX01_HBA_B + N2_FC_B | B |
- Prepare zones for each host-initiator/target pair according to the switch vendor and NetApp-supported zoning convention. The example below uses one initiator and one target per zone so each allowed relationship is explicit.
- Review the active configuration on each fabric. Add the new zones to the existing approved configuration; do not overwrite it with a standalone example configuration. Use the vendor procedure for committing and activating the change.
- Confirm the intended initiator and target are logged in and the zones are active on Fabric A and Fabric B. Keep independent fabric evidence so a later missing path can be localized.
The active configuration contains only the intended new host-to-target pairs and all pre-existing zones are preserved.
03Provision and map the disposable test LUN
- Use an existing SAN SVM with its FC service and target LIFs configured. Choose the correct LUN operating-system type for the ESXi release and supported host guidance. The example uses vmware.
- Create a LUN in a suitable volume, create one igroup for the intended ESXi host, and add its two actual initiator WWPNs. If several ESXi hosts will share a datastore, use an explicitly designed cluster host group; a single-host example is insufficient for that use case.
- Map the LUN to the igroup and capture its path, serial, size and resulting LUN ID. Inspect reporting nodes and any portset binding before rescanning.
lun create -vserver svm_san -volume vol_san -lun lun_esx_lab -size 100GB -ostype vmware -space-reserve disabled
lun igroup create -vserver svm_san -igroup ig_esx01 -protocol fcp -ostype vmware -initiator <actual_hba_a_wwpn>,<actual_hba_b_wwpn>
lun mapping create -vserver svm_san -volume vol_san -lun lun_esx_lab -igroup ig_esx01
lun show -vserver svm_san -path /vol/vol_san/lun_esx_lab -instance
lun mapping show -vserver svm_sanOnly the intended host igroup has the mapping, and the LUN identity is captured before any host formatting.
04Discover and verify the device before creating a datastore
| Evidence | Expected for this example |
|---|---|
| Device identity | Matches the new ONTAP LUN, not an existing datastore |
| Capacity | Matches the requested lab LUN after unit interpretation |
| Adapter coverage | Both planned HBAs have paths to the mapped device |
| Path health | No dead paths; supported ALUA/multipath states |
| Existing workloads | No path changes or I/O errors on unrelated devices |
- Rescan the intended ESXi host using its supported workflow. A rescan is a discovery action; it does not authorize formatting every newly visible device.
- Compare the host device identifier with the ONTAP LUN serial/identity and intended capacity. Inspect paths through both adapters. For this planned topology, four paths can be expected when both HA nodes report the LUN and zoning exposes both targets per fabric. Actual path count and ALUA states depend on platform, mapping and supported design.
- On a traditional AFF/FAS ALUA design, distinguish optimized paths through the owning node from nonoptimized paths through its partner. ASA platforms use a different access model. Apply the NetApp-supported multipathing policy for the actual host rather than assuming a universal policy.
esxcli storage core adapter rescan --all
esxcli storage core device list
esxcli storage core path list
esxcli storage nmp device list05Rehearse one-fabric failure with observable acceptance
- Use only the disposable lab datastore and a controlled I/O workload. Capture path state and guest/application I/O before the test. Arrange a reversible failure of one approved fabric path; do not disturb both fabrics.
- Observe whether I/O continues and whether the path loss is confined to the expected adapter/fabric. Restore the path, confirm it returns to the supported state and inspect host and switch logs.
- If I/O stops, preserve the evidence. Check whether the other fabric actually contains target paths to the reporting nodes, whether the igroup/portset restricts them, and whether multipathing is configured correctly. A count of two HBAs alone does not prove redundancy.
The test workload continues through the surviving fabric and both fabrics are healthy after restoration.
06Troubleshoot a missing device or path without changing healthy paths
For rollback of a new pilot, unmount/remove only the disposable datastore through the supported host process, disconnect its users, then remove the pilot mapping and the specific new zones as approved. Never unmap a shared production LUN because one path is absent. Retain the LUN until data disposal is explicitly authorized.
| Evidence | Likely layer to inspect | Next specific comparison |
|---|---|---|
| No HBA fabric login | Host/optic/cable/switch port | Compare link and port errors with the working HBA. |
| Initiator and target logged in; no contact | Active zoning | Compare actual WWPNs and active membership. |
| Contact exists; no LUN | Igroup, mapping, SLM or portset | Compare host WWPN against intended igroup and reporting nodes. |
| Device present; only Fabric A paths | Fabric B chain | Trace B independently from HBA through target LIF. |
| New-looking device after maintenance | Identity or multipath interpretation | Stop before formatting; compare original serial and datastore. |
Use the section links to revisit a step, or follow a related guide below.
Official references and further reading
Choose the matching release in the vendor documentation before using a command or design. References open on the publisher’s website; linked material remains with its publisher.