Hi Henk, Thanks for the valuable info.
I'm not familiar with the initial boot program so I need some time to understand how it works, may come back with some questions later. Best regards, Jack 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. > > Your problem with the iscsi boot is getting that initial boot program. > > Regards, > Henk >
