Boot Directly from an iSCSI SAN

Once connectivity between the NIC and LUN is established, you can configure your OS. You again have two choices for getting your OS on the new iSCSI target: Migrate an existing Windows installation or perform a clean OS installation. Migration requires a temporary or permanent local disk on the server. Install the OS on the local disk, then configure the OS to boot from iSCSI. Next, use the Sysprep tool to prepare the OS, then image the OS and copy it to the iSCSI LUN. When performing a fresh install of Windows Server 2003 or Windows Server 2008, press F6 during the first part of setup to copy the NIC drivers you need to establish a connection to the LUN. The installation will then proceed as if the iSCSI LUN were a local drive. The OS configuration steps are practically the same whether you're creating a new installation or migrating an old one. Other than where the installation takes place, the primary difference is how NIC drivers are installed in the OS. You should consult your NIC vendor's instructions for the proper driver installation method and order for each scenario. It's important that you configure the NICs to use DHCP within Windows so that their IP address is automatically assigned when the adapter's boot BIOS detects the iSCSI LUN.

Figure 1: Selecting the NIC port(s) to enable for iSCSI boot. Click to expand.

There are a few configuration tasks that are critical to successfully booting from an iSCSI target, whether you specify settings in the NIC bios or via DHCP. First, you need to install the Microsoft iSCSI Software Initiator with integrated software boot support. This installation isn't difficult, but you need to know which NIC port the boot BIOS will use and you need to know whether or not you'll be using MPIO. During the installation, you must check the Configure iSCSI Network Boot Support option and select the NIC port or ports to enable for boot from iSCSI, as shown in Figure 2. Also within the installation wizard, specify whether you're using MPIO. Although you just installed the iSCSI initiator, you shouldn't log on to the target LUN. The initiator will communicate with the boot BIOS to establish and maintain the connection to the target. (To see this process in action, see "How to Use the Microsoft iSCSI Initiator Command-Line Interface.")

After installing the initiator, there are a couple of configuration tasks left to perform. You need to configure the pagefile in the Advanced tab under System Properties. Make sure the pagefile uses a local disk unless the server won't have a local hard drive, in which case you need to turn off the OS's virtual memory capability. If you're running Windows 2003, you should install the hotfix described at support.microsoft.com/?kbid=939875, which corrects a problem with crash dumps on iSCSI boot volumes. Finally, you must add a shutdown script to protect the iSCSI boot sequence configuration from damage related to updates to the network stack. You need to run the Lscsibcg utility included with the Microsoft iSCSI boot software initiator and use the options to fix and verify each time the server shuts down. (For more details about adding the script, see the Microsoft article "How to enable the iSCSI boot sequence on a network adapter after you install the Microsoft iSCSI Boot Software Initiator.")

That's it for OS configuration. Now you're ready to either boot from your iSCSI LUN-based installation or use Sysprep to create an image of your temporary installation and move it to the iSCSI LUN. When you're ready to boot from the iSCSI LUN, modify the boot order or enabled boot devices in your system BIOS; this is where the requirement for system BIOS support for booting from iSCSI comes in. What if you have an older system that was produced before this type of support was mainstream? You can still boot from iSCSI targets with the help of some crafty software tools; see the sidebar "Software-based iSCSI Booting" for more information.

Regardless of which options you use, there are some distinct advantages to using your SAN for boot volumes. Using hardware to boot from iSCSI is easier to support, cleaner, and has fewer "moving parts" than a software solution. Then again, there's no reason you can't use both, if your needs dictate.