Successful Deployment of a Stateless Desktop...

[MultimediaMan]

*Note this is a cross-post from another forum...but I figured it would be better to post it here for effect rather than simply supplying a link.

I am pleased to report the status of my latest IT project...

The Stateless, "Soft" Desktop computer. I deliberately picked a low power system; the next iteration of it will probably be a fire-breathing gaming system of some type, just for laughs.

The Goal: Install, Configure and Run a Workstation from a single network adapter with no local storage devices of any kind (No USB, Optical Media or other temporary storage).

I didn't have a donor system I was comfortable with using for this project. I did some digging and found my old VIA VT310-DP Mini-ITX motherboard languishing in a cupboard: then I remembered why I didn't want to use it... it had no PXE ROM for the onboard VT6122 Gigabit Adapter...or did it? More correctly...Could it?

Long out of warranty...I figured some re-purposing was in order. I made a backup copy of the System BIOS and used CBROM215.exe to peek into the BIOS...



I saw there was ample room withing the 4Mb BIOS image to inject another PXE ROM... finding that PXE Rom was a bit of a problem, but I eventually located it in the driver archives over at VIA's Website; they even had a pre-compiled LOM image...



BIOS ROM Injection proceeded uneventfully. I was taking a (small) chance here on bricking my system: sometimes things don't work out too well when you casually drop another ROM into the BIOS, but I'd done this sort of thing before and knew what to expect. Backing out of a Half-Broken BIOS can be an interesting excercise... read about one of the most difficult-to-solve BIOS problems I encountered here.







I recently had a bad reaction with another manufacturers motherboard with a similar chipset, so I was steeling myself for a fight... which pleasantly, never happened...



With the warranty a distant memory, and all hope of future support a flaming ruin, I proceeded...

The VIA VT310-DP is a great little motherboard...if you liked low power in 2005, and like even less in 2011 (Speaking in terms of Relative CPU Power) this is definitely the ticket. The only thing usual about the VT310-DP was this was VIA most serious attempt to date at an embedded server: it has dual 1GHz Eden processors (Centaur Cores), and runs on top of a CN400 Chipset. It has onboard Unichrome4/PM800 Graphics, the VT8237 Raid Chip which supports Two SATA1 connections and a Single IDE Port. It incorporates a VT6103L 10/100 LOM (PXE enabled), a VT6122 GbE LOM and an Intel 82551QM 10/100 LOM... the latter two onboard components lack any PXE Features. Also included is the VT1616 AC'97 audio controller. The VT310-DP supports a total of 2GB of DDR1 400MHz RAM.

System Configuration: I modded the BIOS to include PXE Support for the GbE LOM; in the BIOS Setup screen I disabled the onboard SATA and IDE Connections, as well as the VT6103L, the VT1616 Audio controller as well as COM2. I put a M-Audio Revolution 7.1 (A VIA VT1724 "Envy" Chip) into the lone PCI Expansion slot.. In Windows, this card is absolutely fabulous when it comes to playback clarity and driver support. I am pleased to say this level of support continues into Linux.

Speaking of Linux Support... I when I tried to install CentOS 6 on this board, it failed... and not for the reason you may expect... the Kernel for CentOS 6 is compiled with certain CPU features which the ageing VIA Eden processors could not support. No matter: the feature set of CentOS 5.7 is very complete and well-developed. My only foible with CentOS 5.7 is that Google Chrome is somewhat broken at the moment... It has dependencies which are not in the 5.7 Kernel; I'll get around to redoing the RPMs to fix that problem in due course, but be warned with CentOS 5.7 i386: Google Chrome is broken.

Here is a picture of the wee beastie on the bench...



For my Testbed, I will be using the Microsoft iSCSI Target. It is a simple applet which can create VHD file and subsequently present them as iSCSI Targets. Up to 256 iSCSI Targets are supported Each iSCSI Target can consist of 256 LUNs...oh yeah... unless you're running microscopic drives, you're gonna run out of Physical Disk Space long before you run out of LUNs or Targets.

The Microsoft iSCSI Client makes use of *.VHDs = virtual hard disks, which are files residing on an NTFS partition which contain the disk images. This allows a certain amount of flexibility when managing disks: running snapshots and outright duplicates can be made of VHD files... potentially greatly simplifying recovery and auditing.

Now it was time to build an iPXE image. You have to build it in Linux... for this I built a Virtual Machine in VMware Workstation. Use your favorite distro: install gcc, mtools, syslinux and git... clone the git tree:

Code:

git clone git://git.ipxe.org/ipxe.git

cd into ipxe/src and make:



Once the core binary is built, you can customize it by embedding instructions into the binary...or calling a script. I chose to embed code into my boot image:



I had to build two customized images...



One for the setup and another for the day-to-day boot...I figured this way was simpler, because of the method I control PXE on my network. You don't need to do this..I will show another method later to do this from a boot script held on a webpage.

Setup Code:

Code:

#!ipxe
set keep-san 1
set initiator-iqn iqn.2003-12.org.centos:proteus-iscsi.olympus.bv.ar.us.local
dhcp net0
sanhook --drive 0x80 iscsi:atlas.olympus.bv.ar.us.local::::iqn.1991-05.microsoft:atlas-proteus-0-target
sanboot --drive 0x81 --no-describe http://epimetheus.olympus.bv.ar.us.local/centos/5.7/isos/i386/CentOS-5.7-i386-netinstall.iso

General Boot Code:

Code:

#!ipxe
set keep-san 1
set initiator-iqn iqn.2003-12.org.centos:proteus-iscsi.olympus.bv.ar.us.local
dhcp net0
sanboot --drive 0x80 iscsi:atlas.olympus.bv.ar.us.local::::iqn.1991-05.microsoft:atlas-proteus-0-target

---

Finally, I mirrored the CentOS distribution tree to my Local Webserver (Epimetheus)...



And so, all that is left to do is boot into setup...after the Target is configured, that is...

I use Windows Storage Server 2008 R2, with the iSCSI Target v3.4 software... If you want a reasonable replacement and don't mind Linux, by all means look into the EIT (Enterprise iSCSI Target) for Linux or FreeNAS for the BSD Crowd. FreeNAS supports all you would probably ever need to even a mid-sized business if you built the underlying hardware robust enough.

In Storage Server2008 R2 you create a new iSCSI Target in the Storage Manager. The Wizard will populate most of the data...



You need to set access rules for the Target... I use simple IQN addresses.



Finally you either create or mount an existing *.VHD file...



You can test this by mounting the iSCSI Target with a software initiator, or go all in and test with iPXE...I tested with a "blank" iPXE bootloader from command line.

Everything now explained (more or less)... here's how it works:

The PC Boots from PXE/ TFTP...



and loads the iPXE Bootstrap program...



with the following parameters:

Code:

#!ipxe
set keep-san 1
set initiator-iqn iqn.2003-12.org.centos:proteus-iscsi.olympus.bv.ar.us.local
dhcp net0
sanhook --drive 0x80 iscsi:atlas.olympus.bv.ar.us.local::::iqn.1991-05.microsoft:atlas-proteus-0-target
sanboot --drive 0x81 --no-describe http://epimetheus.olympus.bv.ar.us.local/centos/5.7/isos/i386/CentOS-5.7-i386-netinstall.iso

1) keep-san tells the bootstrap program to write data to the iBFT.
2) Initiator-iqn sets the iqn of the client to pass to the iBFT.
3) The DHCP command tells the bootstrap program to send a DHCP Request. If you have compiled the UNDI driver, "net0" represents whatever NIC has received a PXE response... in subquent kernels during the boot sequence...net0 becomes eth1.
4) Pay particular attention to the SANHOOK command... it logs into the iSCSI Target and assigns the Local LUN as Disk 0, but does NOT attempt to boot from it. (This information is written to the iBFT).
5) The SANBOOT after the SANHOOK command tells the the initiator to assign the Local LUN as Disk 1, but NOT to write this information to the iBFT (Using the --no-describe argument), and to Boot from a standard HTTP URL path is designated for the boot image.

*The IP Discrepencies are due to the fact it took several boots to grab the Registered SAN Device shot... a screengrab of a video would have been better.

Some interesting things to note... during the PXE Boot, the Bootstrap program is the only thing downloaded using TFTP, and hence, using the UDP Protocol. There is much less chance of corruption with a small binary. After the iPXE Bootstrap program is downloaded, all connections are TCP/IP... that reason alone is justification for using iPXE...the ISO image mount is about 5-10x faster than a UDP Download.

If anyone here has any comments or corrections to make, please feel free to post or IM.

[robinsmidsrod]

Awesome guide, MultimediaMan!

I was able to get FreeDOS and Ubuntu up and running in the similar way, but I didn't need to do any BIOS modding, as my hardware supported PXE booting. Unfortunately I wasn't able to get HTTP ISO booting to work for my setup, so I had to pull the Ubuntu boot process apart and build a kickstart config and such to make it work with my iSCSI target (Nexenta COMSTAR). VMware ESXi 5.0 installed and running as a host on iSCSI storage worked flawlessly as long as I used memdisk to boot the ISO instead of iPXE's HTTP ISO booting method.

[AnRkey]

All the pics are broken

[MultimediaMan]

Fixed itself...apparently.

[Markus]

The explanation about ibft is really helpful for me to see what the san*-related options actually do.

I found the thread while i was searching for a way to let windows 7 installer recognize the ibft. To me it looks like the table is thrown away, while that installer is getting a new IP via DHCP. And so the installer complains the disc visible ist not bootable because
"Windows cannot be installed to this disk. iSCSI deployment is disabled since no NICs referenced in the iBFT can be resolved to actual NT-visible devices".
The strange thing for me is that i managed before to make it work via a simple keep-san, a sanboot to the target (which was empty) and then to chain the bootloader of the windows installation (pxeboot.0). I could install Windows 7 to the target and actually boot it several times, spread over a few days.

By now i am not able to boot windows 7 anymore, nor able to install it to another target.

For setting up the other environments i sometimes changed my dhcp-server. Is it possible that it somewhat kills the ibft with some option?

Best regards,

Markus