From Mark.Carlson@sun.com Fri Jan 8 12:51:49 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o08KpmcO024991 for ; Fri, 8 Jan 2010 12:51:48 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o08Kph6u008417 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Jan 2010 14:51:48 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KVY00B1X4MBI300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Jan 2010 12:51:47 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KVY009YI4MA4I30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Jan 2010 12:51:46 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o08Kpkcr005287 for ; Fri, 08 Jan 2010 20:51:46 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KVY004004CBBZ00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Jan 2010 13:51:46 -0700 (MST) Received: from dhcp-ubrm05-241-14.central.sun.com ([unknown] [129.147.241.14]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KVY00CIJ4M7DJE0@mail-amer.sun.com>; Fri, 08 Jan 2010 13:51:43 -0700 (MST) Date: Fri, 08 Jan 2010 13:51:41 -0700 From: "Mark A. Carlson" Subject: iSCSI Boot patch binding [PSARC/2010/011 Self Review] Sender: Mark.Carlson@sun.com To: PSARC-ext Cc: Jack Meng , Grant Zhang Message-id: <4B479ADD.2090107@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ZgBPDpE2EALbBViBvU3ghA)" X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 Status: RO Content-Length: 22181 This is a multi-part message in MIME format. --Boundary_(ID_ZgBPDpE2EALbBViBvU3ghA) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT I am sponsoring this case for Jack Meng. It requests a patch binding for iSCSI boot, updating PSARC 2008/427 as a result. I do not expect this to be controversial so I have marked it Self Review, but am happy to start a timer if an ARC member so desires or significant discussion ensues. -- mark Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: iSCSI Boot in Solaris with iBFT/OBP 1.2. Name of Document Author/Supplier: Jack Meng (jack.meng@sun.com) 1.3. Date of This Document: 01/08/10 1.3.1. Date this project was conceived: N/A 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Scott.Tracy@Sun.Com 1.4.4. The name of your business unit: Archive Software 1.5. Email Aliases: 1.5.1. Responsible Manager: Grant.Zhang@sun.com 1.5.2. Responsible Engineer: iscsi-boot-iteam@sun.com 1.5.3. Marketing Manager: margaret.hamburger@sun.com 1.5.4. Interest List: iscsi-interest@sun.com 2. Project Summary 2.1. Project Description: This project is to enable Solaris to boot off iSCSI luns via regular network adapters. Different approaches, iBFT/OBP, are adopted to implement this feature on x86/sparc platforms. This case supersedes PSARC/2007/450, iSCSI Software boot. 2.2. Risks and Assumptions: On x86 platform, iSCSI boot depends on NIC's firmware to implement its own iSCSI initiator and to support iBFT to pass boot info to OS. That means the solution on x86 needs dedicated hardware/firmware. Currently Intel 1G/10G Pro. series NICs support this feature along with Broadcom in their high-end NICs. On Sparc platform, iSCSI boot depends on OBP to implement its own iSCSI stack to connect to the iSCSI target, load boot archive, and pass the boot info to Solaris OS via standard OBP properties. A suite of standard properties need to be defined in OBP. iSCSI disk will still be incapable of being a dump device with this project. 3. Business Summary 3.1. Problem Area: Currently Solaris is unable to be boot-off from iSCSI disk. This is a drawback which limits Solaris' competency in iSCSI SAN environment, diskless clients and so on. 3.2. Market/Requester: System Group 3.3. Business Justification: iSCSI boot is required on Solaris in FY09, both on x86 and SPARC platform, because: 1) Sun customers are requesting iSCSI boot options on our Ethernet cards and Storages 2) Intel has iSCSI boot option on their standard NIC for Windows and Linux OS, and Sun can offer this today if we have iSCSI boot on Solaris 3) iSCSI boot is supported on Linux and Windows; therefore we need to reach parity on Solaris 4) iSCSI boot will be the replacement for PXE boot 5) The plan allows iSCSI boot on the standard Network cards without using expensive TOE HBAs. Justification from System Marketing team. 3.4. Competitive Analysis: Linux and Microsoft Windows are capable of booting-off iSCSI disk with the support to iBFT and few other ways(PXE/Boot server). Solaris is significantly behind them in this area and this project is the effort to pace up with those competitors with feasible solutions both for x86 and Sparc. 3.5. Opportunity Window/Exposure: N/A 3.6. How will you know when you are done?: Solaris is able to boot off iSCSI disk with IBFT NIC on x86, and with OBP on SPARC. 4. Technical Description: 4.1. Details: This project enables Solaris to directly boot off iSCSI disk both on x86 and Sparc platform. For doing that it modifies the 'Kernel' stage of Solaris' booting process to enumerate the iSCSI disk with and then mount the rootfs there. Therefore the info of the boot iSCSI target is essential for the kernel to achieve this, and there are completely different ways on x86 and Sparc platform, iBFT/OBP respectively, to pass the info to the ramdisk/kernel. However that info will be unified to the same set of properties so the rest procedure of iSCSI boot is the same for x86 and Sparc. 4.1.1 iBFT on x86 On x86, iBFT is chosen as the method of passing iSCSI boot parameters. iBFT(iSCSI Boot Firmware Table) is defined in ACPI 3.0b specification and is a block of information that contains various parameters that are useful to the iSCSI Boot process. For Solaris by scanning the low memory, it is able to know if it is doing an iSCSI boot and loading necessary parameters then. It is iBF's responsibility to present the iSCSI disk to load OS boot loader and then the ramdisk. 4.1.2 OBP on Sparc On Sparc, kernel reads properties of the boot iSCSI lun from OBP if OBP indicates this is an iSCSI boot. Before that, OBP constructs an iSCSI boot disk with its own iSCSI/TCP/IP stack and loads/executes the booter from there, and then the kernel is loaded and started. Overall, for the Solaris kernel, the only difference regarding iSCSI boot on x86 and Sparc is the way to retrieve info of the boot iSCSI lun as described above. Afterwards it is the same routine to plumb/configure the NIC, load/initialize the iscsi initiator driver, wait for iscsi initiator to discovery the boot target and then mount the rootfs from there. 4.1.3 Security For booting, it is loading OS specific data so the important thing is to make sure that data come from the authenticated server/target. Solaris iSCSI boot uses CHAP (Challenge-handshake authentication protocol, RFC1994) to do ensure the data iSCSI initiator received for booting comes from the target it claims to have come from. IPsec in initiator side is not available during the boot but will take effect after Solaris fully starts up. However, despite the security put in place for this project, Sun will still require customers to have a physically secured network for iSCSI boot, similar to the FC situation. 4.1.4 Dump iSCSI disk is incapable of being the dump device in Solaris, and this project will not address this issue. This is a decision after evaluating benefits/risks of each possible solution. 4.1.5 Installation Both LEGACY and NEW installer (Caiman) will be supported to configure iSCSI disk. The project team are working with the installer team to draft a design. Currently Solaris is able to be installed on iSCSI disk with the LEGACY installer if applying a workaround. 4.1.6 stmsboot stmsboot will be supporting iSCSI along with this project. 4.1.7 Note This project doesn't apply to RFC 4173 and doesn't mean to. 4.2. Bug/RFE Number(s): 6701045 iSCSI boot on X86 6714847 iSCSI boot on Sparc, driver part 6717072 stmsboot needs to support iscsi 6713364 iscsi needs to support PSARC 2008/337 scsi-self-identifying 6422549 delay nl7c_init() call until after the root is mounted 4.3. In Scope: Solaris Kernel, Solaris iSCSI Software Initiator, stmsboot 4.4. Out of Scope: OBP, Solaris Installer 4.5. Interfaces: Imported: Interfaces to load iBFT info on x86, TBD. Exported: Properties in OBP for Solaris OS to load/save iSCSI boot parameters, TBD. 4.6. Doc Impact: TBD 4.7. Admin/Config Impact: Administrator needs to learn how to configure iBFT/BIOS on x86 platform and/or OBP properties on Sparc to enable iSCSI boot. 4.8. HA Impact: Solaris cluster should be able to boot off iSCSI luns, will work with cluster team if they have any special requirement. On x86, Intel's NIC support failover during booting if multiple ports exist and are configured to connect the same target. 4.9. I18N/L10N Impact: N/A 4.10. Packaging& Delivery: N/A 4.11. Security Impact: iSCSI is based on TCP/IP which may expose security vulnerabilities. Please refer to 4.1.3 for more details of the solution. 4.12. Dependencies: Support to Sparc platform depends on case FWSAC 2008/466 which enables iSCSI boot on OBP. 5. Reference Documents: new-boot sparc http://sac.sfbay/PSARC/2006/525 Solaris Boot Architecture http://sac.sfbay/PSARC/2004/454 scsi-self-identifying http://sac.eng.sun.com/PSARC/2008/337 iSCSI Software boot http://sac.sfbay/PSARC/2007/450 Intel iSCSI Boot Support http://www.intel.com/network/connectivity/products/iscsiboot.htm IBFT Specification http://www.microsoft.com/whdc/system/platform/firmware/ibft.mspx Challenge Handshake Authentication Protocol http://www.ietf.org/rfc/rfc1994.txt 6. Resources and Schedule: 6.1. Projected Availability: Q2 FY 2009 for iBFT support (x86 solution) Q3 FY 2009 for OBP support (Sparc solution) and iSCSI support in Solaris installer 6.2. Cost of Effort: 12 engineering months 6.3. Cost of Capital Resources: Approx. capital of $5000 for one LSI iSCSI array. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: ON, NWS 6.4.3. Type of CPT Review and Approval expected: Standard 6.4.4. Project Boundary Conditions: N/A 6.4.5. Is this a necessary project for OEM agreements: N/A 6.4.6. Notes: 6.4.7. Target RTI Date/Release/Binding: Solaris Nevada B104 for x86 Solaris Nevada B127 for Sparc Solaris Update 9 for both x86 and Sparc This feature is required to be backported to S10U9 and requires a patch binding. 6.4.8. Target Code Design Review Date: Aug. 15 2008 6.5. ARC review type: Standard 6.6. ARC Exposure: open 6.6.1. Rationale: N/A 7. Prototype Availability: 7.1. Prototype Availability: Prototype done by Jun 10 2008 7.2. Prototype Cost: 4 engineering months --Boundary_(ID_ZgBPDpE2EALbBViBvU3ghA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT 
I am sponsoring this case for Jack Meng. It requests a patch
binding for iSCSI boot, updating PSARC 2008/427 as a result.
I do not expect this to be controversial so I have marked it
Self Review, but am happy to start a timer if an ARC member
so desires or significant discussion ensues.

-- mark

Template Version: @(#)onepager.txt 1.35 07/11/07 SMI
Copyright 2008 Sun Microsystems

1. Introduction
   1.1. Project/Component Working Name:
	iSCSI Boot in Solaris with iBFT/OBP

   1.2. Name of Document Author/Supplier:
	Jack Meng (jack.meng@sun.com)

   1.3. Date of This Document:
	01/08/10
	
	1.3.1. Date this project was conceived:
		N/A

   1.4. Name of Major Document Customer(s)/Consumer(s):
	1.4.1. The PAC or CPT you expect to review your project:
		Solaris PAC
	1.4.2. The ARC(s) you expect to review your project:
		PSARC
	1.4.3. The Director/VP who is "Sponsoring" this project:
		Scott.Tracy@Sun.Com
	1.4.4. The name of your business unit:
		Archive Software

   1.5. Email Aliases:
    	1.5.1. Responsible Manager: Grant.Zhang@sun.com
    	1.5.2. Responsible Engineer: iscsi-boot-iteam@sun.com
    	1.5.3. Marketing Manager: margaret.hamburger@sun.com
	1.5.4. Interest List: iscsi-interest@sun.com

2. Project Summary
   2.1. Project Description:
	This project is to enable Solaris to boot off iSCSI luns via regular network
	adapters. Different approaches, iBFT/OBP, are adopted to implement this feature
	on x86/sparc platforms. This case supersedes PSARC/2007/450, iSCSI Software boot.

   2.2. Risks and Assumptions:
	On x86 platform, iSCSI boot depends on NIC's firmware to implement
	its own iSCSI initiator and to support iBFT to pass boot info to OS.
	That means the solution on x86 needs dedicated hardware/firmware.
	Currently Intel 1G/10G Pro. series NICs support this feature along with
	Broadcom in their high-end NICs.

	On Sparc platform, iSCSI boot depends on OBP to implement its own iSCSI stack
	to connect to the iSCSI target, load boot archive, and pass the boot info to
	Solaris OS via standard OBP properties. A suite of standard properties need
	to be defined in OBP.

	iSCSI disk will still be incapable of being a dump device with this project.

3. Business Summary
   3.1. Problem Area:
	Currently Solaris is unable to be boot-off from iSCSI disk. This 
	is a drawback which limits Solaris' competency in iSCSI SAN
	environment, diskless clients and so on.

   3.2. Market/Requester:
        System Group

   3.3. Business Justification:
	iSCSI boot is required on Solaris in FY09, both on x86 and SPARC platform,
	because:
		1) Sun customers are requesting iSCSI boot options on our Ethernet
		cards and Storages
		2) Intel has iSCSI boot option on their standard NIC for Windows
		and Linux OS, and Sun can offer this today if we have iSCSI boot on Solaris
		3) iSCSI boot is supported on Linux and Windows; therefore we need
		to reach parity on Solaris
		4) iSCSI boot will be the replacement for PXE boot
		5) The plan allows iSCSI boot on the standard Network
		cards without using expensive TOE HBAs. 
	
	Justification from System Marketing team.

   3.4. Competitive Analysis:
	Linux and Microsoft Windows are capable of booting-off iSCSI disk
	with the support to iBFT and few other ways(PXE/Boot server).
	
	Solaris is significantly behind them in this area and this project is the
	effort to pace up with those competitors with feasible solutions both for
	x86 and Sparc.

   3.5. Opportunity Window/Exposure:
	N/A

   3.6. How will you know when you are done?:
	Solaris is able to boot off iSCSI disk with IBFT NIC on x86, and with
	OBP on SPARC.

4. Technical Description:
    4.1. Details:
	This project enables Solaris to directly boot off iSCSI disk both on x86 and
	Sparc platform. For doing that it modifies the 'Kernel' stage of Solaris' booting
	process to enumerate the iSCSI disk with and then mount the rootfs there. Therefore
	the info of the boot iSCSI target is essential for the kernel to achieve this, and
	there are completely different ways on x86 and Sparc platform, iBFT/OBP respectively,
	to pass the info to the ramdisk/kernel. However that info will be unified to the same set
	of properties so the rest procedure of iSCSI boot is the same for x86 and Sparc.

        4.1.1 iBFT on x86
        
        	On x86, iBFT is chosen as the method of passing iSCSI boot parameters.
        	iBFT(iSCSI Boot Firmware Table) is defined in ACPI 3.0b specification and
	        is a block of information that contains various parameters that are useful
	        to the iSCSI Boot process. For Solaris by scanning the low memory, it
	        is able to know if it is doing an iSCSI boot and loading necessary
	        parameters then. It is iBF's responsibility to present the iSCSI disk
	        to load OS boot loader and then the ramdisk.

        4.1.2 OBP on Sparc
        
	        On Sparc, kernel reads properties of the boot iSCSI lun from OBP if OBP indicates
	        this is an iSCSI boot. Before that, OBP constructs an iSCSI boot disk with its
	        own iSCSI/TCP/IP stack and loads/executes the booter from there, and then the
	        kernel is loaded and started.

	        Overall, for the Solaris kernel, the only difference regarding iSCSI boot
	        on x86 and Sparc is the way to retrieve info of the boot iSCSI lun
	        as described above. Afterwards it is the same routine to 
	        plumb/configure the NIC, load/initialize the iscsi initiator driver, wait for
	        iscsi initiator to discovery the boot target and then mount the rootfs from there.

        4.1.3 Security

                For booting, it is loading OS specific data so the important thing is to make sure
                that data come from the authenticated server/target. Solaris iSCSI boot uses CHAP
                (Challenge-handshake authentication protocol, RFC1994) to do ensure the data iSCSI
                initiator received for booting comes from the target it claims to have come from.
                IPsec in initiator side is not available during the boot but will take effect
                after Solaris fully starts up.
                
                However, despite the security put in place for this project, Sun will still require
                customers to have a physically secured network for iSCSI boot, similar to the FC
                situation.               
                
        4.1.4 Dump
	        
	        iSCSI disk is incapable of being the dump device in Solaris, and this project will
	        not address this issue. This is a decision after evaluating benefits/risks of each
	        possible solution.
	        
	4.1.5 Installation
		Both LEGACY and NEW installer (Caiman) will be supported to configure iSCSI disk.
		The project team are working with the installer team to draft a design.

		Currently Solaris is able to be installed on iSCSI disk with the LEGACY installer if
	        applying a workaround.
	        
	4.1.6 stmsboot
	        stmsboot will be supporting iSCSI along with this project.
	        
	4.1.7 Note
                This project doesn't apply to RFC 4173 and doesn't mean to.
	        
    4.2. Bug/RFE Number(s):
	6701045 iSCSI boot on X86
	6714847 iSCSI boot on Sparc, driver part
	6717072 stmsboot needs to support iscsi
	6713364 iscsi needs to support PSARC 2008/337 scsi-self-identifying
        6422549 delay nl7c_init() call until after the root is mounted

    4.3. In Scope:
	Solaris Kernel, Solaris iSCSI Software Initiator, stmsboot

    4.4. Out of Scope:
	OBP, Solaris Installer
    
    4.5. Interfaces:
        Imported:
                Interfaces to load iBFT info on x86, TBD.
        Exported:
                Properties in OBP for Solaris OS to load/save iSCSI
                boot parameters, TBD.
    
    4.6. Doc Impact:
	TBD
    
    4.7. Admin/Config Impact:
	Administrator needs to learn how to configure iBFT/BIOS on x86 platform and/or
	OBP properties on Sparc to enable iSCSI boot.
    
    4.8. HA Impact:
	Solaris cluster should be able to boot off iSCSI luns, will work with cluster
	team if they have any special requirement.
	
	On x86, Intel's NIC support failover during booting if multiple ports exist
	and are configured to connect the same target.
    
    4.9. I18N/L10N Impact:
	N/A
    
    4.10. Packaging & Delivery:
	N/A
    
    4.11. Security Impact:
	iSCSI is based on TCP/IP which may expose security vulnerabilities. Please refer to
	4.1.3 for more details of the solution.
    
    4.12. Dependencies:
	Support to Sparc platform depends on case FWSAC 2008/466 which enables iSCSI boot on OBP.

5. Reference Documents:
	new-boot sparc					http://sac.sfbay/PSARC/2006/525
	Solaris Boot Architecture			http://sac.sfbay/PSARC/2004/454
	scsi-self-identifying				http://sac.eng.sun.com/PSARC/2008/337
	iSCSI Software boot				http://sac.sfbay/PSARC/2007/450
	Intel iSCSI Boot Support			http://www.intel.com/network/connectivity/products/iscsiboot.htm
	IBFT Specification				http://www.microsoft.com/whdc/system/platform/firmware/ibft.mspx
	Challenge Handshake Authentication Protocol     http://www.ietf.org/rfc/rfc1994.txt

6. Resources and Schedule:
   6.1. Projected Availability:
	Q2 FY 2009 for iBFT support (x86 solution)
	Q3 FY 2009 for OBP support (Sparc solution) and iSCSI support in Solaris installer

   6.2. Cost of Effort:
	12 engineering months
	
   6.3. Cost of Capital Resources:
	Approx. capital of $5000 for one LSI iSCSI array.

   6.4. Product Approval Committee requested information:
   	6.4.1. Consolidation or Component Name:
		ON, NWS
	6.4.3. Type of CPT Review and Approval expected:
		Standard
        6.4.4. Project Boundary Conditions:
		N/A
	6.4.5. Is this a necessary project for OEM agreements:
		N/A
	6.4.6. Notes:
	6.4.7. Target RTI Date/Release/Binding:
		Solaris Nevada B104 for x86
		Solaris Nevada B127 for Sparc
		Solaris Update 9 for both x86 and Sparc
		This feature is required to be backported to S10U9 and requires a patch binding.
	6.4.8. Target Code Design Review Date:
		Aug. 15 2008

   6.5. ARC review type:
		Standard
   6.6. ARC Exposure:
		open
       6.6.1. Rationale:
                N/A

7. Prototype Availability:
   7.1. Prototype Availability:
	Prototype done by Jun 10 2008

   7.2. Prototype Cost:
	4 engineering months
--Boundary_(ID_ZgBPDpE2EALbBViBvU3ghA)-- From Torrey.McMahon@sun.com Fri Jan 8 13:13:36 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o08LDahi025620 for ; Fri, 8 Jan 2010 13:13:36 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o08LDZ9F021809 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Jan 2010 15:13:35 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KVY0010N5MN9700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 08 Jan 2010 13:13:35 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KVY00EXT5MNUL90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 08 Jan 2010 13:13:35 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o08LDYw6012748 for ; Fri, 08 Jan 2010 21:13:34 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KVY001005K1AL00@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 08 Jan 2010 14:13:34 -0700 (MST) Received: from [192.168.0.197] ([unknown] [69.143.17.138]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KVY00B4Y5MM1NC0@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 08 Jan 2010 14:13:34 -0700 (MST) Date: Fri, 08 Jan 2010 16:13:39 -0500 From: Torrey McMahon Subject: Re: iSCSI Boot patch binding [PSARC/2010/011 Self Review] In-reply-to: <4B479ADD.2090107@sun.com> Sender: Torrey.McMahon@sun.com To: "Mark A. Carlson" Cc: PSARC-ext , Jack Meng , Grant Zhang Message-id: <4B47A003.8070702@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B479ADD.2090107@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100108 Lightning/1.0b2pre Shredder/3.0.1pre Status: RO Content-Length: 467 Hi Mark and company. How will the installer, and the customer, know that they can't use the iSCSI boot device as dump device? How does that get squared away with swap devices being the default dump device? Will dumpadm detect that the system is using iSCSI and produce an error? What rev of SPARC OBP will support this? Will the installer be able to differentiate and warn the user they're supported or not based on OBP rev or, on x86, the NIC in the system? From Jack.Meng@sun.com Mon Jan 11 02:42:23 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0BAgNlg023187 for ; Mon, 11 Jan 2010 02:42:23 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0BAgKAU015766 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 11 Jan 2010 04:42:21 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KW200H0DWEKWS00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 02:42:20 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW200I2YWEIDQF0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 02:42:19 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o0BAgILu027925 for ; Mon, 11 Jan 2010 10:42:18 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW200800WBNQN00@mail-apac.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 18:42:17 +0800 (SGT) Received: from [129.158.144.121] ([unknown] [129.158.144.121]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW200JFKWEG46D0@mail-apac.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 18:42:17 +0800 (SGT) Date: Mon, 11 Jan 2010 18:40:04 +0800 From: Ran Jack Meng Subject: Re: iSCSI Boot patch binding [PSARC/2010/011 Self Review] In-reply-to: <4B47A003.8070702@sun.com> Sender: Jack.Meng@sun.com To: Torrey McMahon Cc: "Mark A. Carlson" , PSARC-ext , Grant Zhang Message-id: <4B4B0004.102@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B479ADD.2090107@sun.com> <4B47A003.8070702@sun.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 2141 Hi Torrey, Most things in concern is in documentations, please kindly refer to my answers inline. Torrey McMahon wrote: > Hi Mark and company. > > How will the installer, and the customer, know that they can't use the > iSCSI boot device as dump device? How does that get squared away with > swap devices being the default dump device? Will dumpadm detect that > the system is using iSCSI and produce an error? Currently the installer is unaware of this part. Customer can find this piece of information on the administration guide, located at http://wikis.sun.com/display/OpenSolarisInfo/Configuring+iSCSI+Boot+for+x86+Systems http://wikis.sun.com/display/OpenSolarisInfo/Configuring+iSCSI+Boot+for+SPARC+Systems It is recommended to let administrator decide/configure dedicated dump device in the guide, and by default the dump device is configured as a partition/vol on the iSCSI disk for the case where no local storage is available (commonly seen in iSCSI boot environment). dumpadm doesn't produce errors for such a configuration, and it also will introduce extra work/dependency to make it aware of iSCSI transport. > > What rev of SPARC OBP will support this? Will the installer be able to > differentiate and warn the user they're supported or not based on OBP > rev or, on x86, the NIC in the system? > The prerequisites for SPARC is documented at, http://wikis.sun.com/display/OpenSolarisInfo/Configuring+iSCSI+Boot+for+SPARC+Systems. Specially, the obp version is 4.3.2 and can be confirmed by the presence of 'show-iscsi' command in 'OK' prompt. Unfortunately the differentiation in installer is not present in neither opensolaris (caiman) installer nor the 'legacy' installer for SXCE and S10. There are some technical problems, especially on x86, to determine the capability because of the lacking of unified OS-level interface to check with NIC/firmware from different vendors (unless to perform an iSCSI boot). Therefore administrators need to check the prerequisites section in administration guides listed above and confirm they're met before setting up an iSCSI boot environment. Best regards, Jack From Torrey.McMahon@sun.com Mon Jan 11 07:39:16 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0BFdFv9027800 for ; Mon, 11 Jan 2010 07:39:15 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0BFdEXn028355 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 11 Jan 2010 07:39:15 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KW30020TA5FGS00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 08:39:15 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW300E7KA5ES170@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 08:39:14 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o0BFdDfl015935 for ; Mon, 11 Jan 2010 15:39:14 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW3003009TJ0D00@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 08:39:13 -0700 (MST) Received: from [192.168.0.197] ([unknown] [69.143.17.138]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW300ICGA4W9550@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 11 Jan 2010 08:38:57 -0700 (MST) Date: Mon, 11 Jan 2010 10:38:58 -0500 From: Torrey McMahon Subject: Re: iSCSI Boot patch binding [PSARC/2010/011 Self Review] In-reply-to: <4B4B0004.102@sun.com> Sender: Torrey.McMahon@sun.com To: Ran Jack Meng Cc: "Mark A. Carlson" , PSARC-ext , Grant Zhang Message-id: <4B4B4612.5080703@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B479ADD.2090107@sun.com> <4B47A003.8070702@sun.com> <4B4B0004.102@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b2pre Shredder/3.0.1pre Status: RO Content-Length: 2923 On 1/11/2010 5:40 AM, Ran Jack Meng wrote: > Hi Torrey, > > Most things in concern is in documentations, please kindly refer to my > answers inline. > Torrey McMahon wrote: >> Hi Mark and company. >> >> How will the installer, and the customer, know that they can't use >> the iSCSI boot device as dump device? How does that get squared away >> with swap devices being the default dump device? Will dumpadm detect >> that the system is using iSCSI and produce an error? > Currently the installer is unaware of this part. Customer can find > this piece of information on the administration guide, located at > http://wikis.sun.com/display/OpenSolarisInfo/Configuring+iSCSI+Boot+for+x86+Systems > > http://wikis.sun.com/display/OpenSolarisInfo/Configuring+iSCSI+Boot+for+SPARC+Systems > > It is recommended to let administrator decide/configure dedicated dump > device in the guide, and by default the dump device is configured as a > partition/vol on the iSCSI disk for the case where no local storage is > available (commonly seen in iSCSI boot environment). dumpadm doesn't > produce errors for such a configuration, and it also will introduce > extra work/dependency to make it aware of iSCSI transport. Let me see if I have this straight..... * It's not supported to use the iSCSI boot volume as a dump device under any circumstances * By default the dump device is placed on the boot volume * Ergo, by default, an iSCSI boot device will have dump placed on the boot volume * This project is not going to change the installer or dumpadm command to prevent this from happening * You're hoping the customer reads the docs and changes it manually Right? >> >> What rev of SPARC OBP will support this? Will the installer be able >> to differentiate and warn the user they're supported or not based on >> OBP rev or, on x86, the NIC in the system? >> > The prerequisites for SPARC is documented at, > http://wikis.sun.com/display/OpenSolarisInfo/Configuring+iSCSI+Boot+for+SPARC+Systems. > > Specially, the obp version is 4.3.2 and can be confirmed by the > presence of 'show-iscsi' command in 'OK' prompt. > Unfortunately the differentiation in installer is not present in > neither opensolaris (caiman) installer nor the 'legacy' installer for > SXCE and S10. There are some technical problems, especially on x86, to > determine the capability because of the lacking of unified OS-level > interface to check with NIC/firmware from different vendors (unless to > perform an iSCSI boot). > Therefore administrators need to check the prerequisites section in > administration guides listed above and confirm they're met before > setting up an iSCSI boot environment. This one I'm more ok with as, in theory, you can't set up an iSCSI boot device if you don't meet the prerequisites in the first place. You'll just get an error saying it doesn't work. From John.Fischer@sun.com Mon Jan 11 10:18:08 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o0BII8mu001201 for ; Mon, 11 Jan 2010 10:18:08 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o0BII75U015598 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 11 Jan 2010 11:18:08 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KW300L0BHI7WI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 11 Jan 2010 10:18:07 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW300K3MHI61F30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 11 Jan 2010 10:18:06 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o0BII6Iu014514 for ; Mon, 11 Jan 2010 18:18:06 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW300K00H473300@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 11 Jan 2010 11:18:06 -0700 (MST) Received: from [192.168.10.9] ([unknown] [76.20.56.122]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW300M02HI4R920@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 11 Jan 2010 11:18:05 -0700 (MST) Date: Mon, 11 Jan 2010 10:17:50 -0800 From: John Fischer Subject: Re: iSCSI Boot patch binding [PSARC/2010/011 Self Review] In-reply-to: <4B479ADD.2090107@sun.com> Sender: John.Fischer@sun.com To: "Mark A. Carlson" Cc: PSARC-ext , Jack Meng , Grant Zhang Reply-to: John.Fischer@sun.com Message-id: <4B4B6B4E.6000302@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B479ADD.2090107@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 12055 Mark, I am a little concerned about the Interface section: > 4.5. Interfaces: > Imported: > Interfaces to load iBFT info on x86, TBD. > Exported: > Properties in OBP for Solaris OS to load/save iSCSI > boot parameters, TBD. I would think that there would be a little more detail and not have TBDs since this is self review. Do you have a completed Interface description or table with taxonomy classifications? Thanks, John Mark A. Carlson wrote: > I am sponsoring this case for Jack Meng. It requests a patch > binding for iSCSI boot, updating PSARC 2008/427 as a result. > I do not expect this to be controversial so I have marked it > Self Review, but am happy to start a timer if an ARC member > so desires or significant discussion ensues. > > -- mark > > Template Version: @(#)onepager.txt 1.35 07/11/07 SMI > Copyright 2008 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: > iSCSI Boot in Solaris with iBFT/OBP > > 1.2. Name of Document Author/Supplier: > Jack Meng (jack.meng@sun.com) > > 1.3. Date of This Document: > 01/08/10 > > 1.3.1. Date this project was conceived: > N/A > > 1.4. Name of Major Document Customer(s)/Consumer(s): > 1.4.1. The PAC or CPT you expect to review your project: > Solaris PAC > 1.4.2. The ARC(s) you expect to review your project: > PSARC > 1.4.3. The Director/VP who is "Sponsoring" this project: > Scott.Tracy@Sun.Com > 1.4.4. The name of your business unit: > Archive Software > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: Grant.Zhang@sun.com > 1.5.2. Responsible Engineer: iscsi-boot-iteam@sun.com > 1.5.3. Marketing Manager: margaret.hamburger@sun.com > 1.5.4. Interest List: iscsi-interest@sun.com > > 2. Project Summary > 2.1. Project Description: > This project is to enable Solaris to boot off iSCSI luns via regular > network > adapters. Different approaches, iBFT/OBP, are adopted to implement > this feature > on x86/sparc platforms. This case supersedes PSARC/2007/450, iSCSI > Software boot. > > 2.2. Risks and Assumptions: > On x86 platform, iSCSI boot depends on NIC's firmware to implement > its own iSCSI initiator and to support iBFT to pass boot info to OS. > That means the solution on x86 needs dedicated hardware/firmware. > Currently Intel 1G/10G Pro. series NICs support this feature along with > Broadcom in their high-end NICs. > > On Sparc platform, iSCSI boot depends on OBP to implement its own > iSCSI stack > to connect to the iSCSI target, load boot archive, and pass the boot > info to > Solaris OS via standard OBP properties. A suite of standard > properties need > to be defined in OBP. > > iSCSI disk will still be incapable of being a dump device with this > project. > > 3. Business Summary > 3.1. Problem Area: > Currently Solaris is unable to be boot-off from iSCSI disk. This > is a drawback which limits Solaris' competency in iSCSI SAN > environment, diskless clients and so on. > > 3.2. Market/Requester: > System Group > > 3.3. Business Justification: > iSCSI boot is required on Solaris in FY09, both on x86 and SPARC > platform, > because: > 1) Sun customers are requesting iSCSI boot options on our Ethernet > cards and Storages > 2) Intel has iSCSI boot option on their standard NIC for Windows > and Linux OS, and Sun can offer this today if we have iSCSI boot > on Solaris > 3) iSCSI boot is supported on Linux and Windows; therefore we need > to reach parity on Solaris > 4) iSCSI boot will be the replacement for PXE boot > 5) The plan allows iSCSI boot on the standard Network > cards without using expensive TOE HBAs. > > Justification from System Marketing team. > > 3.4. Competitive Analysis: > Linux and Microsoft Windows are capable of booting-off iSCSI disk > with the support to iBFT and few other ways(PXE/Boot server). > > Solaris is significantly behind them in this area and this project > is the > effort to pace up with those competitors with feasible solutions > both for > x86 and Sparc. > > 3.5. Opportunity Window/Exposure: > N/A > > 3.6. How will you know when you are done?: > Solaris is able to boot off iSCSI disk with IBFT NIC on x86, and with > OBP on SPARC. > > 4. Technical Description: > 4.1. Details: > This project enables Solaris to directly boot off iSCSI disk both on > x86 and > Sparc platform. For doing that it modifies the 'Kernel' stage of > Solaris' booting > process to enumerate the iSCSI disk with and then mount the rootfs > there. Therefore > the info of the boot iSCSI target is essential for the kernel to > achieve this, and > there are completely different ways on x86 and Sparc platform, > iBFT/OBP respectively, > to pass the info to the ramdisk/kernel. However that info will be > unified to the same set > of properties so the rest procedure of iSCSI boot is the same for > x86 and Sparc. > > 4.1.1 iBFT on x86 > > On x86, iBFT is chosen as the method of passing iSCSI boot > parameters. > iBFT(iSCSI Boot Firmware Table) is defined in ACPI 3.0b > specification and > is a block of information that contains various parameters > that are useful > to the iSCSI Boot process. For Solaris by scanning the low > memory, it > is able to know if it is doing an iSCSI boot and loading > necessary > parameters then. It is iBF's responsibility to present the > iSCSI disk > to load OS boot loader and then the ramdisk. > > 4.1.2 OBP on Sparc > > On Sparc, kernel reads properties of the boot iSCSI lun from > OBP if OBP indicates > this is an iSCSI boot. Before that, OBP constructs an iSCSI > boot disk with its > own iSCSI/TCP/IP stack and loads/executes the booter from > there, and then the > kernel is loaded and started. > > Overall, for the Solaris kernel, the only difference > regarding iSCSI boot > on x86 and Sparc is the way to retrieve info of the boot > iSCSI lun > as described above. Afterwards it is the same routine to > plumb/configure the NIC, load/initialize the iscsi initiator > driver, wait for > iscsi initiator to discovery the boot target and then mount > the rootfs from there. > > 4.1.3 Security > > For booting, it is loading OS specific data so the > important thing is to make sure > that data come from the authenticated server/target. > Solaris iSCSI boot uses CHAP > (Challenge-handshake authentication protocol, RFC1994) > to do ensure the data iSCSI > initiator received for booting comes from the target it > claims to have come from. > IPsec in initiator side is not available during the boot > but will take effect > after Solaris fully starts up. > > However, despite the security put in place for this > project, Sun will still require > customers to have a physically secured network for iSCSI > boot, similar to the FC > situation. > > 4.1.4 Dump > > iSCSI disk is incapable of being the dump device in Solaris, > and this project will > not address this issue. This is a decision after evaluating > benefits/risks of each > possible solution. > > 4.1.5 Installation > Both LEGACY and NEW installer (Caiman) will be supported to > configure iSCSI disk. > The project team are working with the installer team to draft a > design. > > Currently Solaris is able to be installed on iSCSI disk with the > LEGACY installer if > applying a workaround. > > 4.1.6 stmsboot > stmsboot will be supporting iSCSI along with this project. > > 4.1.7 Note > This project doesn't apply to RFC 4173 and doesn't mean to. > > 4.2. Bug/RFE Number(s): > 6701045 iSCSI boot on X86 > 6714847 iSCSI boot on Sparc, driver part > 6717072 stmsboot needs to support iscsi > 6713364 iscsi needs to support PSARC 2008/337 scsi-self-identifying > 6422549 delay nl7c_init() call until after the root is mounted > > 4.3. In Scope: > Solaris Kernel, Solaris iSCSI Software Initiator, stmsboot > > 4.4. Out of Scope: > OBP, Solaris Installer > > 4.5. Interfaces: > Imported: > Interfaces to load iBFT info on x86, TBD. > Exported: > Properties in OBP for Solaris OS to load/save iSCSI > boot parameters, TBD. > > 4.6. Doc Impact: > TBD > > 4.7. Admin/Config Impact: > Administrator needs to learn how to configure iBFT/BIOS on x86 > platform and/or > OBP properties on Sparc to enable iSCSI boot. > > 4.8. HA Impact: > Solaris cluster should be able to boot off iSCSI luns, will work > with cluster > team if they have any special requirement. > > On x86, Intel's NIC support failover during booting if multiple > ports exist > and are configured to connect the same target. > > 4.9. I18N/L10N Impact: > N/A > > 4.10. Packaging& Delivery: > N/A > > 4.11. Security Impact: > iSCSI is based on TCP/IP which may expose security vulnerabilities. > Please refer to > 4.1.3 for more details of the solution. > > 4.12. Dependencies: > Support to Sparc platform depends on case FWSAC 2008/466 which > enables iSCSI boot on OBP. > > 5. Reference Documents: > new-boot sparc http://sac.sfbay/PSARC/2006/525 > Solaris Boot Architecture http://sac.sfbay/PSARC/2004/454 > scsi-self-identifying > http://sac.eng.sun.com/PSARC/2008/337 > iSCSI Software boot http://sac.sfbay/PSARC/2007/450 > Intel iSCSI Boot Support > http://www.intel.com/network/connectivity/products/iscsiboot.htm > IBFT Specification > http://www.microsoft.com/whdc/system/platform/firmware/ibft.mspx > Challenge Handshake Authentication Protocol > http://www.ietf.org/rfc/rfc1994.txt > > 6. Resources and Schedule: > 6.1. Projected Availability: > Q2 FY 2009 for iBFT support (x86 solution) > Q3 FY 2009 for OBP support (Sparc solution) and iSCSI support in > Solaris installer > > 6.2. Cost of Effort: > 12 engineering months > > 6.3. Cost of Capital Resources: > Approx. capital of $5000 for one LSI iSCSI array. > > 6.4. Product Approval Committee requested information: > 6.4.1. Consolidation or Component Name: > ON, NWS > 6.4.3. Type of CPT Review and Approval expected: > Standard > 6.4.4. Project Boundary Conditions: > N/A > 6.4.5. Is this a necessary project for OEM agreements: > N/A > 6.4.6. Notes: > 6.4.7. Target RTI Date/Release/Binding: > Solaris Nevada B104 for x86 > Solaris Nevada B127 for Sparc > Solaris Update 9 for both x86 and Sparc > This feature is required to be backported to S10U9 and requires > a patch binding. > 6.4.8. Target Code Design Review Date: > Aug. 15 2008 > > 6.5. ARC review type: > Standard > 6.6. ARC Exposure: > open > 6.6.1. Rationale: > N/A > > 7. Prototype Availability: > 7.1. Prototype Availability: > Prototype done by Jun 10 2008 > > 7.2. Prototype Cost: > 4 engineering months > > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org