>I'd expect to use DHCP and defined a new key (not macro) for this along >the lines of:
... Sorry to dredge this up again, but there is an RFC for iscsi boot. RFC 4173. It describes a form of the root-path dhcp option for iscsi boot: A BOOTP or DHCP server (v4 or v6) MAY instruct an iSCSI client how to reach its boot device. This is done using the variable-length option named Root Path [Alexander93, Reynolds93]. The use of the option field is reserved for iSCSI boot use by prefacing the string with "iscsi:". The Root Path option is not currently defined for DHCPv6; if the option is defined for DHCPv6 in the future, the use of the option as defined for iSCSI boot will apply. The option field consists of an UTF-8 [Yergeau98] string. The string has the following composition: "iscsi:"<servername>":"<protocol>":"<port>":"<LUN>":"<targetname> Now, clearly that only works if the device firmware supports iscsi, because i believe we probably use root-path to define where the boot program (newboot) lives on the server (is that correct?) So we would need a secondary key in dhcp that describes the iscsi boot device path and options if the first level boot is to boot the ramdisk (newboot) from the network and add the iscsi and security stuff to that. It would be a good thing if we worked to standardize that second dhcp key, so it isn't Sun-specific. All vendors have the same issue for supporting iscsi boot on existing network devices that don't support iscsi boot natively in the firmware. We could look for the standard secondary key name and then the sun-specific key name until the secondary key name is standardized. -David
