Host-to-storage provisioning
Outcome
Section titled “Outcome”Connect one host to the intended storage volume through independently verified paths with an auditable mapping.
Inputs
Section titled “Inputs”Approved host name and owners, WWPNs or IQNs, array ports, fabric membership, volume and host-group names, capacity, operating-system multipath policy, change window, and rollback owner.
Procedure
Section titled “Procedure”- Validate identifiers from two sources; never copy an unverified WWPN or IQN into policy.
- Draw the intended paths: host port → switch/fabric or IP network → target port → volume.
- Create narrow single-initiator/single-target zones or the approved site equivalent on each independent fabric.
- Activate according to site policy and confirm effective—not merely defined—membership.
- Map/mask the volume on the array to the correct host identity.
- Rescan the host, confirm one logical device, and verify the expected number and state of paths.
- Test controlled path loss during the approved window, then restore and verify recovery.
- Record identifiers, effective policies, array mapping, device identity, path count, and evidence.
Validation gates
Section titled “Validation gates”- No unrelated initiator gains visibility.
- Both fault domains work independently.
- The host sees one device rather than duplicate unmanaged devices.
- Capacity and immutable device identity match the approved request.
- A reversible path test produces no unexpected application error.
Production boundary
Section titled “Production boundary”The Academy models policy and state transitions; it does not reproduce every vendor parser, licensing rule, fabric service, host driver, or array workflow. Use vendor and site procedures for execution.
Next step
Section titled “Next step”Practice the lifecycle in the zoning module and rehearse recovery with the change-and-rollback runbook.