|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Julian Satran wrote:
Michael,I will have to defer to boot RFC authors. My 2 cents is that DHCP "practice" has already several mechanisms to name the initiator (most based on what the DHCP agents present to the DHCP server - like the real of "fake" (for VMs) MAC address.
I agree that there are several different mechanisms that are used to construct the initiator name. In practice, what we have ended up with is:
iqn.1987-05.com.intel:<hostname> iqn.2000-01.org.etherboot:<hostname> iqn.1995-05.com.broadcom.<184.108.40.206.55.66>.iscsiboot iqn.1986-03.com.ibm.<11:22:33:44:55:66>.<hostname>This is a problem because almost every commercially available iSCSI target uses the initiator name as an identification mechanism to control visibility to target LUNs.
As a result, trying to move from one iSCSI boot initiator to another requires changes on the SAN storage controller (or iSCSI head) to reconfigure for the new initiator name. This is unnecessarily complicated and, in many commercial environments, forces coordination across different organizational units.
And I don't know how the iBFT interacts (or is supposed to) with a DHCP server.
There is no *direct* interaction between the DHCP server and the iBFT. Rather, the values get passed through the iSCSI boot initiator.
The boot iSCSI initiator is responsible for populating the iBFT with the iSCSI parameters that are required to continue to boot the OS once it switches to its protected-mode drivers.
The relevant fields in the iBFT are: * portal hostname/ip addr * portal port * target name * target lun * initiator name * CHAP stuffThe iSCSI boot initiator fills in these fields regardless of whether the parameters come from EEPROM config or from a DHCP server. The values that are filled in are the same values used by the boot initiator for its iSCSI login.
Michael _______________________________________________ Ips mailing list Ips@xxxxxxxx https://www.ietf.org/mailman/listinfo/ips