A SaaS platform blade logs its vHBA into VSAN 20. The array and the zones that should include this blade are in VSAN 10, so the LUN never appears. The SAN boot target is already filled in. What should change?
Select an answer to reveal the explanation.
Short Explanation
The blade drove into the wrong warehouse. You put the vHBA in VSAN 20 while the array and its zones live in VSAN 10, so the login and the LUN are not in the same fabric. A second boot target names another disk, and it does not carry the adapter into the VSAN where the array is actually zoned.
Full Explanation
A vHBA is placed in a VSAN by the service profile, often through the vHBA template or the SAN connectivity policy. FLOGI and zoning then happen inside that VSAN only. This SaaS blade is logging into VSAN 20, while the array and the zones are in VSAN 10, so the fabric that holds the LUN never sees this port name. Moving the vHBA into VSAN 10 puts the login in the same fabric as the zone. A SAN boot target names the array port and LUN used after the vHBA is in the right fabric. Adding another target does not change the VSAN, and the stem already has a target filled in. A UUID is a server identity. It does not select a VSAN. Fabric binding limits which switch WWNs and domain IDs may join a Fibre Channel fabric. It does not rewrite a UCS vHBA from one VSAN into another. Caveat: after the VSAN is corrected, the zone and the LUN mask still have to include this vHBA port name or the disk stays hidden. Operational check: change the vHBA VSAN, confirm FLOGI lands in VSAN 10, and confirm the zone and the array both see that login.