Finding boot devices on a SAN

hafner at hafner at
Fri May 12 07:50:30 PDT 2000

* From the T10 Reflector (t10 at, posted by:
* hafner at


You wrote about finding boot devices in the SAN:
>c) read from all the disk drives that are found, looking
>for signatures previously written
>The Access Controls proposal introduces the concept of a
>central management agent (PAM) that controls policies
>working with targets that implement those policies.
>Something like this could be useful for the boot problem.

In a way, that's already part of the proposal (though not
stated explicitly).
Namely, if PAM uses TransportID only for the purpose of
establishing boot devices and uses AccessID for all other
"rights management", then when an HBA goes looking for
LUNs (prior to drivers getting in the act), the only LUNs
that that HBA will see are the ones based on TransportID.
This can be (should be, and if you want the function you're
looking for, will be) a very small set (one LUN?) that the
BIOS can then look for boot image on.

So, implementing this policy of when to use TransportID and
when to use AccessID solves the problem.  If fact, we left
TransportIDs in there primarily to solve the problem of
boot devices.  One feature of this policy by PAM is that
there is no need for BIOS's or boot device logic to change
(e.g., we don't need to look for special bits in INQUIRY
data to decide if the LUN is a bootable LUN).  So BIOS's can
do exactly what they've already done.

The only problem not solved is the management of HBAs.
If you host has an HBA swap, you can't boot until you
reconfigure the targets ACL.  [But that problem exists
in your scheme, as well, (unless you can get AccessID's
out of BIOS).]

Jim Hafner

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list