Software-Based iSCSI Booting

Even if your system BIOS doesn't support booting from iSCSI, you can use software-based tools to enable iSCSI boot for servers with a Preboot Execution Environment (PXE)-compliant NIC. Double-Take Software makes iSCSI boot tools for clients and servers that offer a few advanced features not found in native hardware iSCSI boot solutions. I'm not aware of any other vendors that provide similar software. I got a copy of winBoot/i (which Double-Take Software has since renamed netBoot/i) 2.5 to see how easily it was to use and how well it would perform. Cost for the software is $995 for the server console, $395 for the server agent, and $95 for the desktop agent.

To demonstrate that booting from an iSCSI target without specialized hardware doesn't require the latest and greatest hardware, I decided to try booting from iSCSI on my old test bed of systems, including a white box Windows 2000 Server system functioning as a domain controller, DNS, and DHCP server. A server running Windows Server 2003 would be the iSCSI boot host.

You need three general components for a functional winBoot/I environment: the winBoot/i Manager, winBoot/i Client, and the iSCSI storage environment. winboot/i Manager runs on Windows Server 2008, Windows 2003, Windows XP, and Windows 2000 Professional and Server. You must have a DHCP server, which can be installed on the same system as winBoot/i Manager or another system. Supported winBoot/i Client OSs include Windows 2003 (32- and 64-bit, Standard or Enterprise) R2 and Windows Storage Server with Service Pack 2.

I followed the Setup and Basic Procedures section of the winBoot/i Getting Started Guide to install and configure the product. The first step, according to the guide, is to provision the boot volume on the SAN. I opened the Dell EqualLogic Group Manager applet and created a 40GB volume for this purpose. Next, I installed winBoot/i Server on the system that hosts my existing DHCP server. Installing winBoot/i on an existing Windows DHCP server lets the installation perform necessary DHCP configurations to support winBoot/i. Alternatively, winBoot/i includes a DHCP proxy utility to support other installation scenarios. The installation routine installed both winBoot/i Server and the PXE bootstrap files. After the installation finished, I launched the Microsoft Management Console–based winBoot/i Manager Console, entered my license information, and clicked the Services icon to verify the winBoot/i, Trivial FTP (TFTP), and PXE services were all running on My winBoot/I server. While still in the console, I created a new client and specified the parameters required for mapping the client to the appropriate iSCSI target when it boots from PXE.

I then performed the winBoot/i Client installation on my server running Windows 2003 R2. The installation routine first installed this hotfix followed by the Microsoft iSCSI Software Initiator and the winBoot/i Client. Per the instructions, after the installation I opened the iSCSI Initiator and logged on to the iSCSI target that I created to house the boot volume. The next step was to launch the winBoot/i SystemCopy utility, shown in Figure A, to copy my existing local installation to the iSCSI volume. SystemCopy is an easy-to-use utility that lets you perform a disk or volume copy to the iSCSI target using Microsoft Volume Shadow Copy Service. If you choose the volume copy option, you must first partition and format the target iSCSI volume. I selected the disk copy option, which replicated my local disk to the iSCSI volume.

I removed the disk I had been using as a boot drive from the server and configured it to boot using PXE on its first NIC. The boot process was simple and fast. It took less than an hour to get from square one to having my client boot from an iSCSI volume.

In my experience, the winBoot/i software–based method for employing boot from iSCSI was easier to implement than hardware solutions, and it has at least one notable advantage over hardware NIC solutions; winBoot/i supports booting Microsoft Hyper-V guest virtual machines (VMs) from iSCSI storage not directly exposed to the Hyper-V host. VMs can be booted from iSCSI storage exposed by the software initiator within the guest VM.