Microsoft Windows boot from SAN
Microsoft supports booting from a Storage Area Network (SAN) if the SAN vendor supports their particular hardware platform booting a Windows server. The SAN and host bus adapter (HBA) must be configured according to the SAN vendor’s guidelines and the SAN vendor must act as the main point of contact for boot-related issues. This requirement exists because booting from a SAN is extremely complex, and the vendor needs to support the particular configuration because the SAN vendor provides the SAN boot supportability statement. It is important to note that the information that is included in this article is not intended to be an all-inclusive list of the items that are required to boot from a SAN. The SAN vendor must provide specific steps, drivers, firmware revisions and resources about how to make their hardware (storage systems, switches, Host Bus Adapters, and so on) work properly together.
The following issues must be addressed so multiple computers can successfully boot from a SAN:
To boot multiple computers from a SAN, the SAN must either be configured in a switched environment, or it must be directly attached from each host to one of the storage sub-system’s Fibre Channel ports. The use of Fiber Channel – Arbitrated Loop (FC-AL) is not supported when booting multipe servers from the SAN because it does not allow the hosts that are attached to the SAN to be properly segregated from each other. A switched environment allows the hosts to be separate from each other. Booting to a SAN with a Fiber Channel-Arbitrated Loop topology is only supported when booting a single server from the SAN.
The host must have exclusive access to the disk that it is booting from. No other host on the SAN should be able to detect or have access to the same logical disk. This can be accomplished by using a type of Logical Unit Number (LUN) management such as LUN masking, zoning or some combination of these methods. LUN management is normally configured at the switch, storage subsystem and/or Host Bus Adapter (HBA) level and not within Windows. Windows provide no capabilities for mapping LUNs.
Multi-path software and multiple HBAs improve your chances of recovery from a path failure. The purpose of having multiple HBAs in a single host is to have redundancy and (possibly) increased throughput. However, if a failure occurs and a path to the SAN is lost, there may be a period of time where the drives on the SAN are not accessible. This path failure may cause problems with the Windows server. Behavior of multi-path software varies greatly between vendors. Check the Windows Catalog (formerly Hardware Compatibility List or HCL) for Storage/RAID systems to make sure that the multi-path driver is in the Windows Catalog with the storage system. If you cannot find the multi-path software, contact your SAN vendor.
To see the Storage/RAID Catalog, please view the following Microsoft Web site:
If the hosts that are attached are part of a Windows 2000 cluster solution, you must use one HBA for the boot process and a separate HBA for shared storage.
If the hosts that are attached are part of a Windows 2000 cluster solution and are using the Microsoft multipath I/O (MPIO) feature, you need four HBAs.
There is a Microsoft document shows how it is
Here a document how windows XP can boot from SAN