[gPXE] Boot from remote SAN as quickly as possible
Gene Cumm
gene.cumm at gmail.com
Sat Nov 13 09:06:54 EST 2010
On Sat, Nov 13, 2010 at 05:05, Erik Loman <erik at surfright.com> wrote:
> Hello all,
>
> I am new to this mailing list and I have several questions.
>
> I saw a YouTube video (from Phoenix) were they show how to boot Windows
> 7 in 10 seconds. I want to do that as well, but this time using a
> diskless PC and boot from a remote SAN. I plan to use Intel Atom boards
> with EFI bios that support Intel Rapid BIOS Boot to minimize bios boot
> time (Intel D510MO).
Could you reference which video?
http://www.youtube.com/watch?v=z9E_Qri8b2E perhaps? This sounds very
interesting.
> I have several questions:
>
> 1. Should I either use iSCSI or AoE? Which one is faster? (the machines
> are on a local network)
AoE doesn't have the overhead of iSCSI (TCP headers, TCP checksum,
etc) but it'll probably also depend on buffering (both sides),
in-flight transactions, the hardware backing the target and other
optimizations. At least the board you referenced has a Gigabit LoM
for a possibility of speed.
> 2. Which iSCSI or AoE target software (for Windows) supports
> non-persistent writes? Which one do you recommend? (either commercial
> or free software)
I'm not sure if you really want non-persistent writes so much as
something like a COW (Copy-On-Write) or snapshot as you'll need to
define when the writes are forgotten. If you do it based on attaching
to the disk, a network interruption will probably cause the the client
OS to freak out and crash as the disk will not be in the state it
expects.
http://www.etherboot.org/wiki/appnotes/cow is one AoE COW example for
Linux. I'm not familiar with any Windows targets.
> 3. I read that gPXE uses DHCP to determine how and what file to boot. Is
> using a boot script significantly faster?
Generally, a script should be faster, especially if you statically
configure your network interface and statically define your boot
target. However, it'll depend on how you load gPXE in the first
place. Using the undionly driver means you PCs will PXE boot (1 DHCP
round) but you won't have any options outside of what PXE normally
requests (ie root-path) unless your DHCP daemon forcibly adds
unrequested options (in which case you'll want gPXE to do a second
DHCP round).
Loading gPXE (with appropriate drivers) from local media (ie, UFD; USB
Flash Drive) could eliminate the first round of DHCP.
> I know, many questions. But if you have an answer to at least one of
> these questions I am very grateful.
>
> Best regards,
> Erik
--
-Gene
More information about the gPXE
mailing list