A media company blade has a SAN boot target in its boot policy, and it still boots the local disk, which is listed first and is bootable. What change makes the blade boot from the array?
Select an answer to reveal the explanation.
Short Explanation
The boot policy is a menu, and the blade eats the first dish that is actually available. You listed a bootable local disk first, so the SAN target sitting underneath it is never reached. Put the SAN target first when the array is the disk this media blade should boot.
Full Explanation
UCS walks the boot policy in order and uses the first device that can boot. The local disk is listed first and is bootable, so the blade loads that disk and does not continue to the SAN target that is already configured. Moving the SAN target ahead of the local disk makes the next boot attempt the array first. An updating template pushes later edits, and an initial template does not. Changing the template type to initial would stop future edits from propagating. It does not cause the profile to ignore a boot order that is already on it. A UUID is an identity for the server. The UUID pool does not choose which boot entry is tried, and adding an address does not reorder the policy. Acknowledging a chassis completes discovery of the hardware. It does not rewrite boot order from the IOM, and the IOM is not the store for the boot policy. Caveat: the vHBA still has to reach the LUN, including zoning and LUN masking, or a corrected order will find no bootable SAN device and fall through. Operational check: put the SAN target first, reboot one blade, and confirm the firmware reports the array LUN as the boot device.