Booting a server from a SAN rather than an image stored on a local disk increases reliability, improves recoverability and greatly eases storage management and administration.
That's the good news.
The bad news is that booting from a SAN is notoriously tricky, involving a thicket of hardware and operating system issues as well as a number of hardware dependencies.
While booting from the SAN hasn't become any easier, it is worth a second look for many storage administrators. The configuration and setup is still a mess, but today there is a lot more help available for storage administrators who want to be able to boot their servers from the SAN.
This help isn't coming from Microsoft, however. Microsoft's attitude toward booting from the SAN is best summed up in the words of the old Firesign Theater routine: "Bombardier it's your karma, baby."
While the Microsoft Web site does provide some helpful details, the company still insists that booting from the SAN is between the customer and the hardware vendor.
Third-party vendors to the rescue
The demand for booting from SAN motivates vendors of host bus adapter (HBA) cards as well as SAN vendors themselves to help their customers configure their SANs for bootability. The result is a steadily increasing flow of white papers, application notes and other help for storage admins.
For example, QLogic Corp., an HBA and RAID vendor, has a 25-page white paper, "Boot From SAN, Part 1" on its
It's a good thing the hardware vendors are so helpful because booting Windows from a SAN is achingly hardware-specific and full of fiddly little details. For instance, the hardware must support SAN booting with features like a boot BIOS in the HBA that supports fabric boot and selectable boot capabilities; and the boot order has to be set correctly.
For QLogic, for example, the boot order should be CD-ROM, diskette and drive 0. In addition, there are a number of operating system details that must be attended to, notably that the server must have a logical unit number (LUN) dedicated to the boot image and the SAN must be zoned properly.
Booting a Windows system requires having a separate boot image in a switched SAN. SANs using Fibre Channel-Arbitrated Loop (FC-AL) need not apply. LUN 0 must be devoted to the logical boot disk and the host must have exclusive access to that LUN. Finally, the boot process must complete quickly enough so that Windows doesn't time out, which typically means five minutes or less.
Start with hardware vendors
Essentially, when a Windows system boots from a SAN, the operating system thinks it is booting from a directly attached disk. The various hardware and software hoops you must jump through are mostly related to maintaining this fiction to the OS.
If you want to pursue booting Windows from the SAN, the best place to start is with your hardware vendors, especially the HBA and RAID vendors as well as the SAN. Ask if your SAN will support booting Windows, and find out what you need to do to make it work. Your hardware vendors should be able to tell you if the process is workable. In fact, it is such a common question that the vendor's staff probably won't have to think about it.
Once you know if it is even possible, the next step is to digest the information on booting from SAN on the vendor's Web site. Typically this will include a fairly detailed description of what is involved. Also, check out Microsoft's Web site for its technical article on booting Windows from a SAN.
While you're on the Web, see what other vendors have in the way of information. Often, each vendor will include details the others leave out. Read and digest all this material until you understand the process thoroughly.
About the author: Rick Cook has been writing about mass storage since the days when the term meant an 80 KB floppy disk. The computers he learned on used ferrite cores and magnetic drums. For the last twenty years, Cook has been a freelance writer specializing in storage and other computer issues.