From sac-owner Thu Apr 23 08:48:53 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3NFmqDA023631 for ; Thu, 23 Apr 2009 08:48:52 -0700 (PDT) Received: from sunmail5.uk.sun.com (localhost [127.0.0.1]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3NFmplF027127 for ; Thu, 23 Apr 2009 16:48:51 +0100 (BST) Received: (from noaccess@localhost) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/Submit) id n3NFmpJI027126 for one-pager-not-2b-used-directly; Thu, 23 Apr 2009 16:48:51 +0100 (BST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3NFmmJl027113 for <@sunmail2sca.sfbay.sun.com:one-pager@sun.com>; Thu, 23 Apr 2009 16:48:51 +0100 (BST) 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 <0KIK0020L99DI300@nwk-avmta-2.sfbay.sun.com> for one-pager@sun.com (ORCPT one-pager@sun.com); Thu, 23 Apr 2009 08:48:49 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIK001IH99CBJ70@nwk-avmta-2.sfbay.sun.com> for one-pager@sun.com (ORCPT one-pager@sun.com); Thu, 23 Apr 2009 08:48:48 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3NFmmNw025341 for ; Thu, 23 Apr 2009 15:48:48 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIK00M008QY6V00@mail-amer.sun.com> for one-pager@sun.com (ORCPT one-pager@sun.com); Thu, 23 Apr 2009 09:48:48 -0600 (MDT) Received: from [192.168.0.11] ([unknown] [206.53.29.107]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIK001SB98X5150@mail-amer.sun.com> for one-pager@sun.com (ORCPT one-pager@sun.com); Thu, 23 Apr 2009 09:48:34 -0600 (MDT) Date: Thu, 23 Apr 2009 09:48:33 -0600 From: Jerry Jelinek Subject: [2009/253]S10C Sender: Gerald.Jelinek@sun.com To: one-pager@sun.com Message-id: <49F08DD1.4030009@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 9247 1. Introduction 1.1. Project/Component Working Name: S10C 1.2. Name of Document Author/Supplier: Jerry Jelinek 1.3. Date of This Document: 04/23/09 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.3. The Director/VP who is "Sponsoring" this project: William Franklin 1.4.4. The name of your business unit: Software 1.5. Email Aliases: 1.5.1. Responsible Manager: Sridhar.Yedunuthula@Sun.COM 1.5.2. Responsible Engineer: Gerald.Jelinek@Sun.COM 1.5.3. Marketing Manager: Duncan.Hardie@Sun.COM 1.5.4. Interest List: zones-core@sun.com 2. Project Summary 2.1. Project Description: Use the BrandZ infrastructure to deliver a Solaris 10 (S10) brand for Solaris.next (S.next). This will be provided as an adoption and compatibility aid to enable customers currently running S10 to easily adopt S.next while also continuing to run their S10 software within branded zones. This allows the customer to rapidly switch over to S.next, creating a win-win situation for Sun and its customers. For customers: - Solution to cope with compatibility differences between Solaris 10 and S.next - Protect investment in Solaris 10 (infrastructure, training, support) - Leverage new technology in S.next (e.g., crossbow) while limiting risk to production environment - Limit total cost of ownership - Avoid or delay required application recertification For Sun: - S.next is adopted sooner - Provide a compatibility environment for S.next - Customers will see Sun as a solution provider who is easing the burden of getting to S.next - Minimize the cost of consolidating Solaris 10 systems - Built-in Solaris feature to aid customer adoption - Provide cross-platform virtualization solution for S.next across all hardware (it is the only M-Series virtualization solution) As with the existing solaris8 [PSARC/2007/350] and solaris9 [PSARC/2008/125] brands, this project will provide a 'physical to virtual' (p2v) capability that can migrate an existing S10 software stack on a physical system into a solaris10-branded zone running on a S.next system. In addition, the project will provide a 'virtual to virtual' (v2v) capability that can migrate existing native S10-based zones into solaris10-branded zones running on a S.next system. This project is planned to deliver as a bundled feature of S.next. 2.2. Risks and Assumptions: The largest technical risk is that S10 and S.next are both continuing to evolve on divergent paths. Because the BrandZ infrastructure interposes on system call traps, with the kernel running S.next and the zone running the S10 userland, any integration to either S.next or S10 that touches both sides of this boundary could potentially break the emulation. This risk requires a range of process-oriented mitigation actions, including modifying the RTI approval process to better manage code changes that could impact the brand, educating the ARCs and developers about the brand, and creating new automated PIT testsuites to catch regressions before integration. A secondary risk is that there is a class of software that will not work properly when it has been moved into a zone because zones only support a subset of the full complement of Solaris features. For example, a customer software stack that depends upon being able to share files via the NFS server will fail inside of the solaris10 branded zone (NFS servers are not supported within zones at this time). Also, software that delivers a kernel component will not directly run. To help address this, projects to close the gaps in functionality within zones should be emphasized. 3. Business Summary 3.1. Problem Area: There are a variety of forces that affect S10 customers: In one direction are pressures pushing the customer to upgrade (for some definition of upgrade) to S.next: - Desire to get the latest S.next features. In the opposite direction are forces pushing the customer to stay on S10: - Resistance from in-house developers and/or the management - Compatibility differences between S10 and S.next - Pressure to "leave alone" systems which "just work" - Pushback from ISVs unable or unwilling to port or certify S.next - High cost, complexity and risk of undertaking migrations - Fear, Uncertainty and Doubt (FUD) about S.next created by competitors 3.2. Market/Requester: Solaris Marketing 3.3. Business Justification: Adoption of S.next will be driven by the new features in S.next but the issues described in 3.1 act to inhibit adoption. This solution removes those inhibitors. 3.4. Competitive Analysis: N/A 3.5. Opportunity Window/Exposure: Marketing has identified this as a required feature for S.next RR. 3.6. How will you know when you are done?: We can install and run a solaris10 branded zone. We can uplift an existing solaris10 system/zone into a solaris10 branded zone. We can pass all of the appropriate S10 tests (e.g., MSTC, stc-threads, etc.) running in the solaris10 zone. We can successfully install and run a top ten (TBD) list of S10 applications in the zone. 4. Technical Description: 4.1. Details: This project is similar to the projects that created the solaris8 and solaris9 brands. We will deliver the solaris10 brand itself. Prototyping for the brand currently requires interposition on 10 system calls out of the ~256 that exist on S10. A p2v and v2v capability will be provided to install the solaris10 branded zone, similar to what exists for the solaris8 and solaris9 brands. 4.2. Bug/RFE Number(s): 4.3. In Scope: - S10 Container creation available at S.next RR - p2v & v2v functionality to transfer S10 based native zones and global zones into solaris10 branded zones running on S.next - Functionality available on any SPARC or X64 platforms that support S.next (including Partners & OEMs) - CLI interface, available for integration with Ops Center and 3rd parties - Versioning support for S10C brand module so that we can detect and support later versions of S10 kernel patches or S10 updates where the emulation must handle the differences - ZFS delegated datasets (possibly in a later release) - Shared stack only for first release, exclusive stack in a follow-on release - A 'preflight checker' will be delivered in a follow-on release that can be used to identify issues on the source system before initiating the migration. - A capability to upgrade a solaris10 zone to a later version of S10 will be provided in a follow-on release. 4.4. Out of Scope: - No support for S10 Updates earlier than S10U8 - Limitations in S10 native zones continue to apply - Trusted extensions - Cross-architecture zone interoperability (SPARC <=> X64) - GUI functionality for S10C - S8C and S9C on S.next - Support for upgrading a solaris10 zone to a native S.next zone (but that might be a future enhancement). 4.5. Interfaces: TBD 4.6. Doc Impact: We believe that this product will require a new administration guide. We believe that the work done for the solaris8 and solaris9 brand administration guides can be leveraged. At least one man page will also be required. 4.7. Admin/Config Impact: A new brand (solaris10) will be defined for zonecfg(1M). We will not support installing this brand using the S10 media-based installer. Instead we will install the zone from either a system or zone image (just as we do with the solaris8 and solaris9 brands). 4.8. HA Impact: NA 4.9. I18N/L10N Impact: There will likely be some new messages within the zone's deliverable that will need to be localized. 4.10. Packaging & Delivery: Since this is a branded zone, there is no impact on regular software management. S10 patches will have to be applied from within the zone. The project may be delivered as one or more packages, but this has not yet been determined in detail. 4.11. Security Impact: None. 4.12. Dependencies: This depends on PSARC/2005/471 BrandZ: Support for non-native zones which has been integrated. 5. Reference Documents: PSARC/2005/471 BrandZ: Support for non-native zones PSARC/2007/350 Etude: Migration Technology PSARC/2008/125 Etude Part Deux 6. Resources and Schedule: 6.1. Projected Availability: Beta release in Q1CY10 6.2. Cost of Effort: 3 people for 6 months 6.3. Cost of Capital Resources: None, existing resources will be used. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: ON 6.4.3. Type of CPT Review and Approval expected: Standard 6.4.4. Project Boundary Conditions: 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: 6.4.7. Target RTI Date/Release: Sept '09 6.4.8. Target Code Design Review Date: 6.4.9. Update approval addition: 6.5. ARC review type: Standard 7. Prototype Availability: 7.1. Prototype Availability: Now 7.2. Prototype Cost: 2 people for one month