Server+ PBQ Lab: Storage Path Outage

The correct answer is to restore the HV-02 storage-b path configuration on SW-STOR-B so the storage VLAN and MTU match the intended jumbo-frame storage design, remove any bad target-discovery entries, rescan HV-02 storage, verify DS-PROD-01/LUN 12 and two optimized MPIO paths, and then recover DB-01, API-01, and WEB-01 in dependency order.

This is correct because the outage is not caused by a failed SAN, a bad application service, or a missing datastore. The evidence points to a degraded storage path on one hypervisor host after network maintenance. HV-02 is the affected host, and the impacted workloads all depend on DS-PROD-01/LUN 12. The storage array still presents the production LUN, the controllers are healthy, and a comparison host still has healthy access. That rules out a broad storage-array failure.

The critical detail is that the second iSCSI path is not fully healthy even though basic connectivity appears to work. Small pings can succeed, but storage I/O still fails or flaps because the storage-b path no longer matches the jumbo-frame configuration used by the host and storage network. The switch-side path reverted to an incorrect configuration after maintenance, leaving HV-02 with degraded multipath access. Restoring the correct storage VLAN and MTU on SW-STOR-B fixes the underlying transport problem rather than treating a symptom.

The answer also correctly requires validation before application recovery. After fixing the storage path, HV-02 must rescan storage and confirm the correct production LUN, not merely any visible datastore. Two optimized MPIO paths must be verified so the host is no longer operating through a single degraded path. Only after storage latency and path health are corrected should DB-01, API-01, and WEB-01 be recovered in dependency order. That order matters because restarting applications before stable storage is restored can produce temporary or misleading results while the root cause remains.

Replacing a disk group or rebuilding the RAID pool is incorrect because the array evidence does not show a failed disk group, degraded RAID state, or controller-side storage failure. The production datastore problem is host/path-specific, not a SAN-wide hardware failure. Treating it as a RAID incident would add unnecessary risk and downtime without addressing the broken storage-b path.

Restarting DB-01, API-01, and WEB-01 as the primary fix is incorrect because the application errors are downstream symptoms of storage latency and path instability. The services are timing out because their underlying VM storage is unhealthy. Restarting them before correcting the iSCSI/MPIO path may briefly change the symptoms, but it does not restore stable access to the datastore.

Mounting DS-ARCHIVE-02 or another visible datastore is incorrect because visibility is not the same as correctness. The affected workloads depend on DS-PROD-01/LUN 12. Mounting a different datastore does not repair the degraded production storage path and could create additional operational risk by moving or attaching workloads to the wrong storage target.

Recreating the iSCSI discovery entry with a new target IQN and CHAP secret is incorrect because the evidence does not show that the correct production target was replaced or that CHAP should be changed. A wrong IQN, look-alike target, or mismatched CHAP value can create authentication failures or stale discovery entries. Disabling multipathing is especially wrong because the problem is degraded multipath resiliency; removing MPIO would make the environment less redundant and could worsen the outage.

Changing HV-02 vmk2 to MTU 1500 is incorrect because it normalizes the host down to the broken switch state instead of restoring the intended storage-network design. The environment is designed for jumbo frames on the storage path. Small pings succeeding at MTU 1500 do not prove storage I/O is healthy. The correct fix is to restore consistency across the storage path, including the switch configuration, so large storage traffic and multipath failover operate correctly after the next reboot.