A game studio blade logs its vHBA into the Fibre Channel fabric, then boots from the local disk. The boot policy lists no SAN target. The LUN is on an array that the fabric can already reach. What should be added so the blade boots from that LUN?
Select an answer to reveal the explanation.
Short Explanation
Logging into the fabric only gets the server to the front door of the SAN. You still have to tell the boot policy which array WWPN and which LUN to open. A new UUID changes who the blade claims to be, and it does not choose the boot disk.
Full Explanation
A successful vHBA login means the blade's Fibre Channel identity can reach the fabric. Boot-from-SAN still requires the boot policy to put SAN ahead of the local disk and to name the storage target. The target entry carries the array port WWPN and the LUN ID the operating system should boot. Without that entry, the firmware falls through to the local disk, which is the studio's symptom. A LAN PXE target is an Ethernet boot method. The blade's management IP is not an iSCSI portal, and this failure is on a vHBA path, not a PXE path. A UUID pool entry gives the service profile a stable identity. It does not identify a LUN. Fabric binding on an MDS restricts which switches may join the fabric. The array is already reachable, so a missing switch-binding entry is not why the blade ignores the LUN. Caveat: zoning and the LUN masking on the array still have to permit this vHBA, or a perfect boot target will see no disk. Operational check: add the primary SAN target with the correct WWPN and LUN, move SAN above the local disk in the boot order, and confirm the next POST shows the array LUN as the boot device.