Henk Langeveld wrote: > Jack wrote: > > We're working on the iSCSI initiator in Solaris, it utilizes TCP/IP >> protocol in kernel (so*) to enumerate block devices on the local >> host. Users may need to access these block devices in an early >> booting up time, e.g., by mount points in /etc/vfstab, or use them as >> shared DID or quorum device in Cluster environment. >> >> However a problem here is that iscsi devices could be inaccessible >> during the boot time due to the route to the iSCSI target (probably >> in another subnet) is not established yet. That issue is getting hot >> since people keep asking to use iSCSI device on cluster environment. >> >> I'm curious about if NFS met this problem problem before and how got >> solved. Thanks. > > Hi Jack, > > NFS solved this by staging the boot process. > The bootprom acquires an ip address through rarp or dhcp, and uses the > ip address as an index to an extended boot program, loaded with tftp, > with > some assistance from the bootparams protocol. > > All of these protocols are based on udp, and are expected to be available > on the LAN. Some routers may support 'helper' addresses which redirect > those udp requests to resources on a different (V)LAN. > > The boot program is a self-contained unit and is supposed to > understand the filesystem you're trying to boot from. This also > understands the bootparams > protocol (DHCP for x86, I assume) and may set the default route from > there. A subsequent nfs root mount may then cross over into another > network. > So here the booter knows about the nfs, it sets up the routing to load the boot archive(ramdisk), and then the ramdisk triggers the kernel, but how does the kernel know the routing to mount the root file system? Booter passes the info to it or by some other ways?
Thanks, Jack > Your problem with the iscsi boot is getting that initial boot program. > > Regards, > Henk >
