Hi Frank,
Frank Ludolph wrote: > Hi Jan, > > Very nice writeup! > > Only one comment. Under 6.2, I believe that is necessary to only > identify the architecture in order to insure that the client gets an > architecturally compatible NPB. I agree in general. But based on Sundar's comments, it seems there are scenarios in which utilizing existing DHCP server for this mechanism is not possible, as collision would occur - in that case per-client setup might be used as 'fallback mechanism'. > The NBP would then provide the MAC address, IP address, and other > relevant system hardware information to the AI server in order to > determine the appropriate service/manifest to be used. I think this is interesting point - for the time being, NBP is really limited in its functionality and only serves for obtaining enough information to be able to launch second stage of boot process - which means loading kernel and ramdisk from appropriate AI image. For x86 that information has to be configured in DHCP server as well - source of GRUB menu.lst file. It seems like an interesting area for the investigation - if we embed some 'discovery mechanism' into x86 NBP itself, then we could further diminish the dependency on DHCP server. We are in better position for Sparc, as the location of AI image (kernel/ramdisk) is obtained using wanboot mechanism - which is independent on DHCP server. However, the limitations of current implementation are the same as far as process of locating AI image is concerned. > > This also limits the number of client DHCP macros to one for each > architecture. Agreed. It is assumed to work in this way modulo the issues we have identified so far. Thank you very much for your comments ! Jan > > Frank > > > > Jan Damborsky wrote: >> Hi Caimaniacs, >> >> As part of install service redesign project, the following problem >> was identified and captured below along with investigation done and >> proposed high level approach how to address it. >> Please yell with questions/comments :-) >> The outcome of this discussion will be reflected in install service >> functional specification. >> >> Thank you, >> Jan >> >> >> [1] Problem statement >> --------------------- >> Boot AI client from network in deterministic way in heterogeneous >> client environment using DHCP without need for client specific setup. >> >> [1a] Current state >> ------------------ >> In current implementation, if both Sparc as well as x86 AI clients >> are configured to be served by one DHCP server without creating >> per client DHCP configuration, unpredictable behavior can occur. >> x86 client can be provided with Sparc NBP or vice versa based on >> the order of configuration steps accomplished. >> >> [2] Scope of the problem >> ------------------------ >> Only early stage of network boot process which serves for obtaining >> NBP is covered here as this is where x86 and Sparc share the boot >> mechanism and where undeterministic behavior could occur. >> Once NBP is obtained, different subsequent boot mechanisms are used >> by x86 >> and Sparc. >> >> For x86, PXEgrub downloads GRUB menu.lst file containing information >> about what to boot in the next stage. >> >> For Sparc, wanboot-cgi script locates wanboot.conf file containing >> the similar set of information. >> >> [3] Definition of terms >> ----------------------- >> NBP >> - network bootstrap program >> - PXEgrub for x86, wanboot-cgi for Sparc >> >> heterogeneous client environment >> - both Sparc & x86 clients are present >> >> AI environment >> - everything which is necessary to allow AI client to be successfully >> deployed using Automated installer - e.g. >> - DHCP server >> - TFTP server >> - AI server providing AI images, install services, AI manifests >> to AI clients using HTTP protocol >> - ... ? >> >> heterogeneous AI environment >> - parts of AI environment are deployed across >> different platforms - e.g. DHCP server running on Linux >> AI server running on Solaris 10 >> >> per client scope >> - applies to AI clients with client specific setup >> >> general scope >> - applies to AI clients without client specific setup >> >> [4] Requirements >> ---------------- >> * AI network boot process has to be deterministic >> * AI network boot process has to work in heterogeneous environment >> without need for client specific setup >> * AI boot process can be configured in heterogeneous AI environment >> - modification of shared pieces (existing DHCP server in this case) >> will be supported and will be as less intrusive as possible >> >> [5] Supported configurations >> ---------------------------- >> * local/remote Sun DHCP server deployed on OpenSolaris & Solaris 10 >> * local/remote ISC DHCP server deployed on OpenSolaris, Solaris 10, >> Linux >> >> [6] Feasibility study >> --------------------- >> The purpose of technical feasibility study is to do initial research >> if technologies to meet the functional requirements exist. >> >> [6.1] Constraints >> ----------------- >> Constraints are determined by the existing technologies AI has to >> plug into. >> >> client side: >> * PXE boot for x86 and early stage of DHCP net boot for Sparc. >> >> server side: >> * DHCP server >> >> [6.2] AI client identification >> ------------------------------ >> In order to provide client with correct NBP, client has to identify >> itself >> to the DHCP server in some way. For the time being, following >> information >> are passed as part of DHCPDISCOVER message which initiates DHCP >> handshake: >> >> x86 PXE client (see [1] for more details): >> * MAC address >> * UUID >> * system architecture (DCHP option 93 - e.g. 0 for x86) >> * class identifier (DHCP option 60 string: >> "PXEClient:Arch:xxxxx:UNDI:yyyzzz, >> "PXEClient:Arch:00000:UNDI:002001" is the only known to be implemented >> for the time being) >> * ... >> >> Sparc: >> * MAC address >> * class identifier (DHCP option 60 string: "SUNW.*", e.g. >> "SUNW.Sun-Fire-v210") >> >> Based on this observation, it seem that there is a way to meet >> the functional requirements taking existing constraints into account: >> >> * per-client scope >> identify client on DHCP server by MAC address >> >> * general scope >> distinguish between x86 & Sparc client architecture by >> inspecting client class identifier string >> >> [7] Proposed high level solution >> -------------------------------- >> Set up DHCP server, so that NBP correctly matching client platform >> will be selected by inspecting client class identifier provided by >> particular AI client. >> >> [8] Deliverables >> ---------------- >> * define DHCP server configuration parameters for supported DHCP >> server implementations for per-client scope and general scope >> (e.g. format of client class identifier macros for SUN DHCP server >> and how they will plug into whole DHCP server configuration) >> >> [9] Related problems/interdependencies >> -------------------------------------- >> * installadm redesign >> - mechanism/API for obtaining valid up-to-date list of client >> class identifiers for Sparc platform >> - mechanism for local/remote update of supported DHCP server >> implementations >> >> * following stages of boot and process of establishing working AI >> client install environment >> >> [10] Related documentation >> -------------------------- >> [1] Preboot Execution Environment Specification v2.1 >> http://download.intel.com/design/archives/wfm/downloads/pxespec.pdf >> >> [2] PXE Wiki >> http://en.wikipedia.org/wiki/Preboot_Execution_Environment >> >> [3] Setting up PXE netboot for x86 clients >> http://www.riddleware.com/solx86/PXE/pxe-netboot.html >> >> [4] Supported AI scenarios and use cases >> http://www.opensolaris.org/os/project/caiman/auto_install/ai_svs_redesign_scenarios.txt >> >> >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
