Storage Admin HubConfiguration · Protection · Recovery
All guides/Interview Q&A
Interview Q&A · ONTAP 9

SAN scenario-based interview questions

Missing LUN, lost path, high latency, thin provisioning and disaster recovery.

Scenario

These are incident-style questions. A strong answer names the evidence to collect before touching the host or the storage mapping, then states a safe change and its validation.

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. A new iSCSI LUN is not visible on a Linux host.

  1. Confirm the exact initiator IQN and host OS type. Check connectivity from each intended NIC to the target portal, iSCSI discovery/session status, the SVM iSCSI service and online LIFs. Then check igroup membership, LUN online state, mapping and reporting nodes. Only after the path exists should you rescan the SCSI bus and check multipath.
  2. Do not format a similarly sized existing device. Record the expected LUN serial and LUN ID, compare them with host output, and test through both networks. If one session works and another fails, isolate that NIC/VLAN/route/target LIF before recreating the LUN.
Read-only ONTAP checks 
vserver iscsi show -vserver svm_prod
network interface show -vserver svm_prod
igroup show -vserver svm_prod
lun mapping show -vserver svm_prod
Verify

The host discovers the expected unique LUN through the supported number of paths.

2. An FC host lost all paths on fabric B, but fabric A works.

  1. Scope the failure to one HBA, switch, target port or entire fabric. Inspect the host HBA link and errors, switch port and active zoneset, target LIF online state and WWPN, then ONTAP mapping and SLM reporting nodes. Do not make zoning changes on both fabrics at once.
  2. Compare the healthy A path to B: initiator WWPN, target WWPN, login, zone membership and physical light level. Fix the faulty segment under change control, rescan the HBA and confirm multipath restores its expected path states before a failover test.
Read-only ONTAP checks 
network interface show
lun mapping show -fields reporting-nodes
system health alert show
Verify

Fabric B paths return with no I/O outage and no unexpected device duplicates.

3. Paths are visible but host I/O latency suddenly rises.

  1. Separate host queueing from network/fabric errors and ONTAP latency. Compare one host and LUN against others on the same switch and aggregate. Inspect path states: if optimized paths disappeared, the host may be using longer non-optimized routes. Check HBA/NIC errors, link negotiation, switch congestion and host multipath failover logs.
  2. Correlate with ONTAP node, aggregate, volume, QoS and disk latency at the incident time. Review recent moves, takeovers, firmware or driver changes. Restore the failed preferred path or address the measured resource bottleneck, then compare the original application workload and baseline.
Verify

The answer includes a before/after measurement at host and storage layers.

4. A thin-provisioned LUN reports free host space but writes fail.

  1. Host file-system free space and ONTAP backing capacity are different measurements. Check LUN space reservation, containing volume free space, snapshot consumption, aggregate physical headroom and any space-allocation/UNMAP behavior. Identify whether ONTAP is returning out-of-space errors and which layer is exhausted.
  2. Protect existing recovery points and check replication dependency before deleting snapshots. If physical headroom exists and an approved change permits it, grow the volume or add backing capacity; confirm the host writes resume. Configure thresholds for volume and aggregate so the next growth event is detected earlier.
Read-only capacity checks 
lun show -fields space-reserve
volume show-space
storage aggregate show
volume snapshot show
Verify

Application writes succeed and aggregate physical space supports future growth.

5. During takeover, a host loses its LUN despite dual fabrics.

  1. Collect the host multipath event timeline, ONTAP takeover status and target LIF/session state. Verify that the surviving fabric and partner paths were actually available, correctly zoned or routed, and included in the LUN reporting nodes. Seeing two paths on the same failing component is not true redundancy.
  2. Check host driver/multipath settings against its NetApp Host Configuration, ALUA behavior, supported timeouts, switch events and takeover readiness. Correct the single point of failure in a scheduled change and repeat a controlled test rather than forcing another takeover during the incident.
Read-only investigation 
storage failover show
network interface show
lun mapping show -fields reporting-nodes
Verify

Sustained I/O during a later approved single-path and HA test.

6. After SnapMirror DR activation, ESXi sees a duplicate datastore.

  1. Stop before mounting or resignaturing anything. Determine the LUN serials and whether the old primary or a snapshot/replica is also presented to the same host. Verify which site is authoritative, whether the destination volume is writable, and whether host igroups and zoning expose both copies simultaneously.
  2. Follow the VMware and NetApp procedure for the intended recovery mode: resignature, mount existing signature, or present to isolated DR hosts as appropriate. Change one presentation at a time; validate VMs and datastore identity with the application owner. Protect the old source from writes until failback direction is chosen.
Verify

Exactly one production copy is active for the intended hosts, and datastore recovery is documented.

NetApp references