Booting from the SAN rather than a local drive makes servers easier to manage and (usually) faster to restore in the event of a problem. However, in the case of Windows, setting up to boot from a SAN is complex.
So complex, in fact, that a Microsoft white paper on the subject recommends storage administrators consider the pros and cons carefully before even trying it.
If you run into problems in setting up Windows Server 2000 or 2003 to boot from the SAN, there are several things you need to check. They include issues with hardware, configuration and some inherent limits in Windows.
The most basic requirement for booting Windows Server from a SAN is that the hardware will support it. The most critical piece of hardware for SAN booting is the Host Bus Adapter (HBA). Not all HBAs will support this feature and many of the ones that will typically ship with their boot BIOS disabled. Only one per server should have the boot BIOS enabled.
A SAN boot also requires the appropriate HBA drivers. Microsoft recommends using the Storport driver rather than the more common SCSIport miniport driver with Windows Server 2003. The driver is available from the HBA manufacturer rather than Microsoft.
Boot-from-SAN symptoms—and what to do about them
Each server on the SAN needs its own boot drive. That means you need to designate as many boot drives in the storage array as there are servers accessing that storage, and the server must have access to the correct boot disk. This requires setting the HBA boot BIOS to the address of the disk or LUN.
The most common symptom of a boot-from-SAN problem is that the system can't locate the boot partition and boot files. Although possible causes include boot sector viruses and hardware failure, the most common causes are configuration issues. The problems are especially likely to show up after the power cycles because turning the power off and on can change the identification of things like storage devices and Logical Unit Numbers (LUNs).
One difficulty is that the devices can be re-enumerated in a different order when the power comes back on. Since LUN 0 must be assigned to the controller, according to SCSI-3 standards, and since the controller has to discover the LUN lists for each adapter for a successful boot, this can cause boot failure. In theory, LUN 0 is always assigned to the controller, but according to Microsoft, not all manufacturers follow this convention.
One solution is to use HBAs that support LUN mapping and will automatically re-assign the LUN IDs as appropriate.
Windows also uses the target ID (which is assigned by the HBA) rather than the WWN (which is assigned by the manufacturer) to identify devices for booting from the SAN. These target IDs follow the SCSI naming convention. Since Microsoft doesn't support persistent binding of the SCSI target ID, a la FC-AL, it's important to make sure the HBA is still identifying the device correctly.
You should also check to see which Windows HBA driver is installed. As mentioned earlier, boot-from-SAN configurations need to use the Storport miniport driver. The SCSIport miniport driver will work in a boot-from-SAN configuration, but it won't work well and it is subject to damaging crashes.
Since the HBA is so critical in a boot-from-SAN configuration, it pays to check and re-check the setup routine configuration in each individual HBA.
Even if everything is set correctly, you can still have problems if too many servers are trying to boot from the same storage array. If the fabric connection becomes saturated, the requests will time out and the system can crash.
For a more complete description of booting Windows from a SAN, see Microsoft's white paper, "Boot from SAN in Windows Server 2003 and Windows 2000 Server."
Rick Cook has been writing about mass storage since the days when the term meant an 80K floppy disk. The computers he learned on used ferrite cores and magnetic drums. For the last 20 years he has been a freelance writer specializing in storage and other computer issues.
