From owner-freebsd-scsi@FreeBSD.ORG Fri Mar 16 16:16:29 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1025116A400 for ; Fri, 16 Mar 2007 16:16:29 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id D942613C46A for ; Fri, 16 Mar 2007 16:16:28 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from localhost (jn@ns1 [69.55.238.237]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id l2GFxVXl071526; Fri, 16 Mar 2007 11:59:32 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-hackers@freebsd.org Date: Fri, 16 Mar 2007 11:59:37 -0400 User-Agent: KMail/1.9.5 References: In-Reply-To: X-Face: #X5#Y*q>F:]zT!DegL3z5Xo'^MN[$8k\[4^3rN~wm=s=Uw(sW}R?3b^*f1Wu*.<=?utf-8?q?of=5F4NrS=0A=09P*M/9CpxDo!D6?=)IY1w<9B1jB; tBQf[RU-R<,I)e"$q7N7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200703161159.37735.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-scsi@freebsd.org Subject: Re: iSCSI boot mussings X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 16:16:29 -0000 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