I wanted to boot Windows 7 from an iSCSI SAN, implemented withan OpenSolaris 2009.06 ZFS server. In theory,Windows 7,like Vista, 2008, 2008 R2, can be installed directly to an iSCSI target,but these instructions did not work for me. They require booting from LANto register the iSCSI target as BIOS drive 0x80 with gPXE, and letting gPXEexit to rely on the BIOS then falling back gracefully to DVD-ROM boot in orderto launch the Windows installer which would then detect BIOS drive 0x80 —theiSCSI target— and install on it. The first problem was that when gPXE exited,the BIOS would not fall back to DVD-ROM boot. Instead it forced me to press akey to reboot. So I wrote a custom COM32 program to, from gPXE, call intothe BIOS via interrupt 19h to 'load the OS'.This worked. Interrupt 19h forced my BIOS to boot from DVD-ROM, launching theWindows installer.But then, even though the installer detected the iSCSI target, saw the correctsize, was able to partition and format it, it refused to install on it.'This computer's hardware may not support booting to this disk. Ensure thatthe disk's controller is enabled in the computer's BIOS menu'. All I saw,after pressing shift+F10 to get a shell and read setupact.log, was the sameerror message and that the drive did not have the'canInstall' capability. There was not a single clue of what was wrong.KB933925 was unhelpful.
OmniOS/ZFS/Windows 7: “Save as” from within applications lags 5 seconds for all file sizes over CIFS/SMB. Ask Question Asked 4 years, 1 month ago. Active 4 years, 1 month ago. Viewed 803 times 9. Situation: The following strange problem has occurred on a single file server running OmniOS r151018 (95eaa7e) serving files over SMB to. A network accessible zfs inside windows 7, which reports it as NTFS. I can do a 'map network drive' in windows 7, and I now have a 10 terabyte ntfs drive in windows 7. Obviously it is not bootable. And it is only as reliable as all of the hardware it is composed of.
Frustrated, and vividly reminded why I despise Windows (an open source OS would have let me inspect the code and fix the bug), I did not want to have toinstallWindows 7 on iSCSI via WinPE as it seemed too much work.So I resigned to install the OS on a regular physical disk first, then to transfer theimage to an iSCSI target.Of course more hurdles came on the way, but I was able to resolve them.Hopefully my documented experience will save trouble to others who would liketo enjoy the convenience of diskless booting Windows 7 via iSCSI:
- Install Windows 7 on a physical disk. When selecting a partition size (eg.30000MB), if the disk is unpartitioned, the installer may forcefully create asmall ~100MB system partition and a larger one of size 30000MB minus ~100MB.Be aware of this detail when transferring the image to the iSCSI target in later steps.
- Disable the LightWeight Filter (LWF) driver for the NIC that will beused for iSCSI boot. As explained inKB976042 this drivercannot start at boot time and would prevent the NIC from being availableduring iSCSI boot.One way to unbind the LWF driver from the NIC is to use bindview.exe which has tobe compiled from the Windows Developer Kit(!) If you are like me and prefer easiersolutions, do this by editing the registry (thanks toTakahiroWagatsuma for this information):
- Open HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlClass{4D36E972-E325-11CE-BFC1-08002BE10318}
- Find and open the subkey for the NIC (eg. 0007)
- Open the subkey Linkage
- Edit the value FilterList. Delete the line that refers to the LWF driver UUID {B70D6460-3635-4D42-B866-B8AB1A24454C}. In my case I had to delete the second line. Before: After:
- On OpenSolaris: enable iSCSI, create a ZFS filesystem.I use OpenSolaris 2009.06, but any recent Solaris version should work the same.Enable the iSCSI target daemon and create afilesystem that will be dedicated to hosting the Windows image,so it can be independently snapshotted, cloned, etc:
- Transfer the disk image to OpenSolaris.I boot the Windows machine into Linux, and use dd and ssh to transfer theimage to OpenSolaris. Verify the partition sizes (remember that the installer may havecreated 2 partitions):Copy the range of disk sectors that will include the MBR and these 2 partitions,that is the first 206848 + 61233152 = 61440000 sectors, or 61440000 * 512 = 31457280000 bytes.This number of bytes is exactly 30000*1024*1024 because I chose '30000MB'during installation. However always verify the sizes with sfdisk because sometimesI have noticed the installer adds 1 extra MB. I use dd and ssh to stream the imageover the network to my OpenSolaris server:
- On OpenSolaris, create the iSCSI target.First, snapshot the image (it will be useful):Then create the iSCSI target from it:Immediately after iscsitadm create, OpenSolaris will start rewriting theentire image file over itself in order to force the allocation of all data blocks(thick image).This will take multiple minutes during which the iSCSI target is not reallyavailable (if you try to boot from it using gPXE, it will throwInput/output errors —it took me a while to find the cause of these errors).IMHO there should be an option to disable thick allocation.Anyway, monitor the progress of the rewrites with zfs list:You will know they are finished when the 'USED' space will have doubled(because thanks to the snapshot, the non-rewritten blocks have been preserved—I told you it would be useful!):When the rewrites are done, roll back to the snapshot, if only to reduce the usedspace back to normal:
- Configure gPXE to offer booting Windows 7 from SAN.I will assume that you have a pre-existing DHCP setupserving gPXE configured to read a menu file that simply needs to beupdated with the Windows 7 option. If not, follow one of thenumerous gPXE HowTo guides.The gPXE menu file should be edited to add (replace x.x.x.x with theIP address of the OpenSolaris server, and the IQN with the one outputearlier by iscsitadm list):Where cmd.c32 should be extracted from thesyslinux 3.86tarball and placed in the TFTP directory. I have not tried the newer 4.x versionsbut they should work.
- This is it, test it!Remove the physical disk from the Windows machine, boot via PXE,select the win7 menu option, and enjoy your new Windows 7 environment.
Diskless machines booted from an iSCSI SAN implemented with an OpenSolaris ZFSserver allow you to do powerful things. You can:
- 'zfs rollback' to revert a machine to snapshot.
- 'zfs clone && iscsitadm create target' to quickly provision a new machine (modulo the forced thick allocation).
- 'zfs destroy' to get rid of it.
Zfs Windows Driver
Essentially, many of the features that are typically only available tovirtualized environments are made available to physical machines.I have multiple diskless Linux machines that I use for my own GPGPU developmentprojects. This setup gives me the option to run some tests under Windows 7 as well.Given that I frequently move GPUs from one machine to another, swap hardwarecomponents, upgrade or revert the OS/drivers, diskless booting and snapshottingcertainly make my life much easier. If the above instructions to boot Windows 7from iSCSI are useful to you, let me know!