|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
This issue may be something that you are already aware of, and may be something that you are already working to address.
(I am going to ignore the related issues of CHAP username and secret)rfc4173 [http://tools.ietf.org/html/rfc4173 Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol) defines the protocol for passing boot target information to an iSCSI boot client via DHCP options. Unfortunately, it does not define a mechanism for passing an InitiatorName to be used by the iSCSI boot initiator. The omission of this has led to differences in the InitiatorName in different iSCSI boot implementations.
Many iSCSI target servers depend upon the iSCSI InitiatorName to control visibility to target LUNs. The inability to control InitiatorName through DHCP leads to interoperability issues as one tries to dynamically move between systems with different iSCSI boot implementations.
I am not familiar with iSNS (Internet Storage Naming Service http://tools.ietf.org/html/rfc4171) but I assume that the InitiatorName probably plays a key role in identification.
I am familiar with several currently available implementations of iSCSI initiators ... hardware, firmware, and software. see listing below.
The hardware and firmware implementations of iSCSI boot initiators (QLogic, Intel, Broadcom, IBM) allow one to define static initiator and target login information in EEPROM on the client. In addition, they all support a DHCP assigned iSCSI boot target per RFC 4173.
The etherboot/gPXE implementation only supports assignment of iSCSI boot parameters via DHCP.
Implementations generally construct the InitiatorName by trying to include the DHCP option 12 hostname. They take a base iSCSI Qualified Name prefix and concatenate the hostname supplied by the DHCP server. You end up with:
iqn.1987-05.com.intel:<hostname> iqn.2000-01.org.etherboot:<hostname> iqn.1995-05.com.broadcom.<220.127.116.11.55.66>.iscsiboot iqn.1986-03.com.ibm.<11:22:33:44:55:66>.<hostname> <hostname> represents the hostname provided in DHCP option 12. <18.104.22.168.55.66> represents the MAC address of the initiator NIC.This might work fine in a static data-center environment where dedicated applications run on dedicated hardware. Even a mixed environment with different vendors involved is generally not a problem as long as each system is configured individually ... and as long as no system changes are required.
However, data centers and data center configurations are not static. They frequently have a need to move from one hardware configuration to another. Common examples are a planned hardware upgrade of an existing system and an emergency hardware replacement for a failed system. A more extreme example would be an offsite disaster-recovery scenario.
Machine virtualization tools such as vmWare and Zen facilitate moving images between systems, easing the transition between system hardware.
Data center virtualization systems such as Scalent automate assignment of SAN-based applications to available servers in the server pool, effectively enabling a data center to run any application on any available physical or virtual machine.
Migrating iSCSI boot images from one system to another is problematic if the iSCSI boot implementations differ between the old hardware and new hardware. On many/most commercial iSCSI target servers the visibility/mapping/zoning configuration would have to change because of the differing iSCSI InitiatorName. This is a problem because it usually requires coordination across organizational units.
Take the case where one has an application running on an IBM server using iSCSI boot. iSCSI boot parameters are being assigned via DHCP. One wishes to move this application to an HP server with an Intel NIC that supports iSCSI boot. Both iSCSI initiators support DHCP assignment of the iSCSI target. However, since the full InitiatorName is not specified via DHCP, the SAN administrator must also make a change on the iSCSI SAN storage controller in order to make the appropriate LUN(s) visible to the new/different initiator name.
Vendor ExtensionsBroadcom and IBM seem to have foreseen this oversight in rfc4713. From available documentation it is unclear to me whether or not they have adopted exactly the same mechanism as a workaround for assigning the iSCSI boot initiator name. I am in the process of obtaining hardware so that I can verify behavior.
Broadcom documentation indicates that they support a DHCP vendor extension that allows one to fully specify the InitiatorName from the DHCP server. Support for an option such as this would mean that boot-from-iSCSI-SAN images could be moved between systems by only making changes on the DHCP server. See http://ftp.us.dell.com/network/Bcom_LAN_11.0_4.1_Manual_A01.exe
Draft IBM documentation at ftp://ftp.software.ibm.com/systems/support/system_x_pdf/39y9159.pdf indicates that the initiator name can be set using DHCP vendor option 203 … but it isn’t very specific … and I have not been able to verify this.
I have also been told that the Microsoft WHQL (Windows Hardware Quality Labs) requirements for iSCSI boot make reference to “DHCP option 203”. I am trying to obtain these documents.
ConclusionThere needs to be a standard IETF mechanism, perhaps an extension to rfc4713, that defines what InitiatorName is to be used when iSCSI booting.
I am interested in participating in the discussion and am willing to help however I can.
Michael Howard Scalent Systems michael.howard@xxxxxxxxxxx ---- Internet Small Computer Systems Interface (iSCSI) http://tools.ietf.org/html/rfc3720 Internet Small Computer Systems Interface (iSCSI) Naming and Discovery http://tools.ietf.org/html/rfc3721 String Profile for Internet Small Computer Systems Interface (iSCSI) Names http://tools.ietf.org/html/rfc3722 Internet Storage Naming Service (iSNS) http://tools.ietf.org/html/rfc4171 Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol http://tools.ietf.org/html/rfc4173 ---- QLogic * hardware iSCSI HBAs * proprietary drivers for Win + Linux * http://qlogic.com/Products/SAN_products_iSCSI.aspx * supports DHCP assignment of target parameters Intel * iSCSI boot firmware for selected server-class NICs * works in conjunction with MSFT initiator under >= win2k3 * http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=15864 * iqn.1987-05.com.intel:<hostname> Broadcom * iSCSI boot firmware for selected server-class NICs * works in conjunction with MSFT initiator under >= win2k3 * http://www.broadcom.com/collateral/wp/FSC-BRCM-iSCSI-BOOT-White-Paper.pdf * iqn.1995-05.com.broadcom.<22.214.171.124.55.66>.iscsiboot * Vendor extension DHCP option 43 suboption 203 IBM * iSCSI NIC firmware in selected blades/servers * works in conjunction with MSFT initiator under >= win2k3 * http://www.alphaworks.ibm.com/tech/sancommander * ftp://ftp.software.ibm.com/systems/support/system_x_pdf/39y9159.pdf * vendor extension option 203 emBoot * software PXE/UNDI implementation * proprietary windows initiator under XP & win2k with netBoot/i * works with MSFT initiator under >= win2k3 * http://emboot.com/iscsiboot.htmemBoot uses a proprietary mechanism in their netBoot/i and winBoot/i products to assign login information to their software initiator. emBoot does not support DHCP assignment of iSCSI boot parameters. Therefore, the discussion of DHCP assignment of iSCSI boot parameters is not applicable to emBoot’s current products.
etherboot/gPXE * open source PXE/UNDI/NIC driver implementation * works with MSFT initiator under >= win2k3 * http://etherboot.org/wiki/index.php * only (?) supports DHCP assignment of iSCSI boot parameters per RFC 1473. THE END _______________________________________________ Ips mailing list Ips@xxxxxxxx https://www.ietf.org/mailman/listinfo/ips