Date: Fri, 16 Mar 2007 11:59:37 -0400 From: John Nielsen <lists@jnielsen.net> To: freebsd-hackers@freebsd.org Cc: freebsd-scsi@freebsd.org Subject: Re: iSCSI boot mussings Message-ID: <200703161159.37735.lists@jnielsen.net> In-Reply-To: <E1HSAhj-000KwL-By@cs1.cs.huji.ac.il> References: <E1HSAhj-000KwL-By@cs1.cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 16 March 2007 07:34, Danny Braniss wrote: > Hi, > Now that I have my hands on a server that can boot iSCSI, > I started to look into it. After figuring out what magic is needed > in the dhcpd.conf (just add option root-path > "iscsi:target-ip::::target-name") I can boot FreeBSD to the point that it > can't find a root device, and assuming that some more magic can be applied > (ala NFS), I'm just > wondering aloud, if it's realy worth the efford. > For a PXE based diskless solution, you need > 1 - a working dhcpd > 2 - a working tftpd > 3 - a working NFS server with the exported root fs. > appplying some minor magic, you can have only one read-only fs. > For an iSCSI based diskless solution, you need > 1- a working dhcpd > 2- a working iscsi-initiator, unless the BIOS can be used. > 3- a working target with a root fs > (one for each client, unless applying 3 from the above). > Hybrid solution: > boot via PXE, but mount root via iSCSI > > So, what say you all? =46rom the kernel's perspective (at the moment just prior to mounting root)= , is=20 there a difference between the last two approaches? The situation as I see = it=20 (in both cases) is that the kernel is loaded into memory (by some magical=20 means which is at this point irrelevant), and now has to locate a root devi= ce=20 using only what it already has to bootstrap the process. If what it already= =20 has includes BOOTP code then it's possible to get some additional informati= on=20 externally. Whether the initial magic was PXE or BIOS-based iSCSI, the kern= el=20 has to have its own storage drivers and do its own network setup, right? I think there are some benefits to being able to do this, but perhaps 90% o= f=20 them could be realized with what we already have (iscontrol and the=20 iscsi_initiator kernel module) plus some rc and fstab glue. Any kind of=20 diskless server farm needs at least one "master" server to run dhcpd, and i= f=20 you have it doing that you might as well have it do NFS and tftpd as well.= =20 Pretty much any client you'd want to use as an iSCSI initiator will have a= =20 decent NIC which nowadays implies PXE support. So it shouldn't be hard to g= et=20 root mounted using currently available means (local disk or PXE+NFS), and=20 from there have the option of using iSCSI for other partitions=20 (including /usr). A truly standalone iSCSI client will most likely want to use a TOE card, wh= ich=20 to the OS looks like any other SCSI adapter. (I'm unsure which if any such= =20 cards are currently supported in FreeBSD, but that's a tangential question.) Machines with iSCSI-capable BIOS'es are an inbetween case. Allowing such=20 machines to be standalone clients would require things like the initiator=20 name, the initiator's IP address and netmask, the target's IP address, and= =20 the target's (volume) name to be hard-coded in the kernel. It would be nice= =20 to support this scenario, but IMO it's the one with the lowest benefit/cost= =20 ratio. Making it easy to integrate iSCSI into existing environments (diskless or n= ot)=20 is IMO the biggest hole in the current implementation (the missing rc and=20 fstab bits I mentioned before). JN
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200703161159.37735.lists>