From sac-owner Tue Aug 16 06:25:30 2005 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j7GDPUEu019281 for ; Tue, 16 Aug 2005 06:25:30 -0700 (PDT) Received: (from noaccess@localhost) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) id j7GDPTw18591 for one-pager-not-2b-used-directly; Tue, 16 Aug 2005 06:25:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j7GDPTD18582 for <@sunmail2.sfbay.sun.com:one-pager@sun.com>; Tue, 16 Aug 2005 06:25:29 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0ILB00705HAHA200@nwk-avmta-1.sfbay.Sun.COM> for one-pager@sun.com (ORCPT one-pager@sun.com); Tue, 16 Aug 2005 06:25:29 -0700 (PDT) Received: from phorcys.East.Sun.COM ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0ILB00JC4HAGJ3E0@nwk-avmta-1.sfbay.Sun.COM> for one-pager@sun.com (ORCPT one-pager@sun.com); Tue, 16 Aug 2005 06:25:29 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j7GDPSWA009911 for ; Tue, 16 Aug 2005 09:25:28 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j7GDPSWL009908; Tue, 16 Aug 2005 09:25:28 -0400 (EDT) Date: Tue, 16 Aug 2005 09:25:28 -0400 From: James Carlson Subject: [/]Zones Upgrade (Ashanti and Zulu) To: one-pager@sun.com Message-id: <17153.59720.512090.93407@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.0.3.165339 Status: RO Content-Length: 13475 Template Version: @(#)onepager.txt 1.29 04/11/15 SMI This information is Copyright 2005 Sun Microsystems, Inc. 1. Introduction 1.1. Project/Component Working Name: Zones Upgrade (Ashanti and Zulu) 1.2. Name of Document Author/Supplier: James Carlson 1.3. Date of This Document: 08/15/2005 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: beverly.crair@sun.com 1.4.4. The name of your business unit: Solaris 1.5. Email Aliases: 1.5.1. Responsible Manager: victor.nelson@sun.com 1.5.2. Responsible Engineer: james.d.carlson@sun.com 1.5.3. Marketing Manager: jeff.mcmeekin@sun.com 1.5.4. Interest List: zones-upgrade@sun.com 2. Project Summary 2.1. Project Description: The Zones Upgrade project makes it possible to upgrade a Solaris 10 FCS system configured with non-global zones to any later update or release. There currently is no way for a customer to upgrade a Solaris system once non-global zones are installed; the user must remove the zones in order to upgrade. 2.2. Risks and Assumptions: If this project doesn't ship, then it will not be possible to support upgrading to Solaris 10 Update 1 on systems that have non-global zones configured. Users must configure their systems in certain ways in order to make the upgrade process work correctly. We must document ways to reconfigure existing systems to work with the proposed scheme. Other parts of the organization must deliver components of the solution, including information from Release Engineering and potential changes to the default initial software installation procedure and the systems shipped to customers (even those prior to Solaris 10). The longer-term goal is to push customers away from standard upgrade and towards the use of Live Upgrade. The project consists of multiple phases as an approach to delivery, and technical differences among these phases may cause customers to become confused or annoyed. 3. Business Summary 3.1. Problem Area: This project addresses the need to upgrade Solaris 10 FCS systems to Update 1 and beyond. Currently, the upgrade process (both standard upgrade and Live Upgrade) cannot be run on a system that has non-global zones installed. The necessary support was not included in Solaris 10 FCS. Systems not using Solaris Zones, likely the majority of S10 users, are unaffected, but the lack of support for Solaris Zones is a particular problem because it has been promoted so strongly as an important feature of Solaris 10. 3.2. Market/Requester: TBD customer list. Although many customers simply never upgrade (and instead rely on patches, and reinstall if they ever want to go to a new version), at least some customers who are using Solaris Zones are likely to want to upgrade, and all will be confused with the message Sun will be forced to send if upgrade support is omitted. 3.3. Business Justification: Lack of upgrade support threatens a significant new feature (Solaris Zones) for Solaris 10, which is the flagship software product of a USD$12.62B company. 3.4. Competitive Analysis: All competitive products include upgrade mechanisms. None are known to prohibit upgrade when normal features are used, let alone highly-touted ones. 3.5. Opportunity Window/Exposure: It is needed by Solaris 10 Update 1. 3.6. How will you know when you are done?: It must be possible to upgrade a Solaris 10 FCS system containing multiple zones to Solaris 10 Update 1 and beyond. Customers must be able to read, understand, and deploy the set of instructions we provide for updates on existing Solaris 10 FCS systems. 4. Technical Description: 4.1. Details: The project has two phases, termed the "interim solution" and the "permanent solution." The goal of the interim solution (project code name "Ashanti") is to ship quickly, so that Solaris 10 Update 1 is not delayed excessively. The goal of the permanent solution (project code name "Zulu") is to build a more supportable and robust offering for a later update. Both solutions rely on the ability to run commands within a zone that is not running on (and cannot be run on) the current system. This ability comes from a new feature called a "scratch zone" that constructs a miniroot-like environment in which to administer the contents of the zone. An important overall design consideration is that shared items are marked read-only, while unshared ones are read-write. This allows the various packaging and patch tools to fail when the system is misconfigured. The interim solution uses scratch zones to install patches and fixed lists of packages into the system in order to make the contents of the system equivalent to one that undergoes a normal upgrade. The permanent solution relies on Zones-aware extensions to Live Upgrade to perform the normal upgrade procedure: computing lists of packages to remove and add based on the contents of each zone and the system itself. It's possible that each of these solutions will have separate ARC cases to discuss details outside the scope of this case. 4.2. Bug/RFE Number(s): 4976161 PSARC 2003/460 Admin/Install Zones Support (Phase IV: luupgrade zone aware) 5108905 pkgadd -Z functionality is unimplemented 5108917 pkginfo -z unimplemented in pkgcmd pkg 6222815 cannot patch a SUNW_PKG_THISZONE=true pkg in a local zone 6236796 patchrm of a SUNWcsu patch in a local zone should fail as it has SUNW_PKG_ALLZONEs=true 6256515 zone install fails after adding patch 6263190 adding a patch that patches an architecture specific package ie SUNWcakr gives misleading output 6264796 live upgrade does not process configured zones when creating and processing boot environments 6267966 after applying patches to an S10 zones system, pkgchk fails for a lot of packages in the local zone 6268085 patchrm is not backing out files delivered for the first time in the patch 6274438 cannot patch a system with a zone in "configured" state 6275530 package commands do not process configured zones when -R is given path to global zone 6275531 patch commands do not process configured zones when -R is given path to global zone 6290368 patch's 119254-04 and 119255-04 do not fix bug-id 6263190 6290429 Patch script fails cause patchadd to run the patchrm cmd in the local zone, instead of the global 6290432 patchadd exits 0 (success) on patchadd failures 6292233 patchadd still does not support incremental patching 4.3. In Scope: User experience in performing the upgrade -- from default install options, zone configuration, through the individual steps required to perform the upgrade itself -- are an important component of this project. Recovery from various possible error states that may occur during upgrade is part of this project. Performance of the upgrade path is an important issue. 4.4. Out of Scope: The project does not address standard upgrade, though many of the issues and solutions required for that are based on the work done here. The project does not support "famous directory" configurations for zones other than the existing whole and sparse root models. 4.5. Interfaces: Solaris Zones commands -- zoneadm, zonecfg, zlogin -- are given an "-R" (alternate root) option to access alternate boot environments and the mounted system root in a miniroot environment. A new zone state -- "mounted" -- is added to the list of user- level zone states. In the "mounted" state, the zone is not running and cannot be booted, but can be entered with zlogin, and has its root mounted on "/a" inside the zone, just like a regular miniroot. The "/a" mount point is read-write (and thus can be upgraded) if there are no zones that reference it. Alternate boot environments are supported with zones by creating alternate names for the zones; a private infrastructure for mapping these names is created. The packaging and patch tools use the new "mounted" state to modify zone contents, regardless of the location of the zone, and to accept private options to select particular zones on which to act. The "lumount" command is given a "-a" option to mount all filesystems within the specified boot environment. Those that are shared are presented as read-only lofs mounts. A new private library based on the existing pfinstall logic is created to compute package update lists for zones that are to be upgraded. This logic will eventually replace pfinstall. Various other consolidation private utilities (such as lusync) are updated to address zones. A "/b" mount point for the previous boot environment root is established. 4.6. Doc Impact: Solaris Information Products writing resources have been approved for this project. 4.6.1. Ashanti (Interim solution) doc impact: Solaris 10 Installation Guide: Basic Installations Writers: Lynne Thompson and Chris Franklin Solaris Installation Guide: Custom JumpStart and Advanced Installations Writers: Lynne Thompson and Chris Franklin System Administration Guide: Solaris Containers--Resource Management and Solaris Zones Writer: Penny Cotten What's New release item Writer: Lynne Thompson This project will require modification to the following man pages: Modification of existing NOTES sections: patchadd(1M) patchrm(1M) pkgadd(1M) pkgadm(1M) pkgask(1M) pkgchk(1M) pkgrm(1M) luupgrade(1M) live_upgrade(5) Add reference to Solaris Installation Guide: Custom JumpStart and Advanced Installations for supported custom JumpStart keywords: flash_archive(4) 4.6.2. Zulu (Permanent solution) doc impact: Revisions made to the documents for the interim solution could be modified or removed. In addition to the documents listed above, the document "Solaris 10 Installation Guide: Solaris Live Upgrade and Upgrade Planning" (Lynne Thompson and Chris Franklin) could require changes. Additional documentation requirements might be identified for the permanent solution. 4.7. Admin/Config Impact: See section 4.5 above; new administrative commands are available for use with zones and LU. The user will need to configure his system in a certain way in order to perform any upgrade. (This configuration includes separating the roots of zones between boot environments so that the upgrade process does not cause running bits to be modified. The actual implementation refuses to run rather than modify anything in active use.) The normal LU upgrade process, however, will not necessarily require any special flags or interface changes to perform the function. 4.8. HA Impact: N/A 4.9. I18N/L10N Impact: A small number of new messages from admin/install need to be localized. 4.10. Packaging & Delivery: Two patches (neither requiring reboot) are necessary to deliver the functionality into an existing Solaris system. Once these are installed, no special packages or other package changes are needed. 4.11. Security Impact: The new scratch zone feature is required to solve some security issues (namely that packaging related scripts cannot be trusted once a zone has been booted, and must always be executed in zone context), but itself has complex security issues. In particular, the requirement to mount (read-only) certain special directories into the scratch zone (/lib, /usr, /sbin, /platform) carries with it some risk of "leaking" private bits, such as licensed software, from the global zone into private whole-root zones. This can be mitigated by constructing a "pristine" zone from which to mount these required directories, but the cost may be high. 4.12. Dependencies: Future deliveries of Solaris are dependent on being able to upgrade. This project does not depend on other projects. 5. Reference Documents: Project web site (design, schedule, team): http://installzone.sfbay/projects/zones/ "Admin/Install Zones Support" (PSARC 2003/460) "Virtualization and Namespace Isolation in Solaris" (PSARC 2002/174) "Clarification of Cross-Zone Descriptor Restrictions" (PSARC 2004/357) 6. Resources and Schedule: 6.1. Projected Availability: Ashanti: November 2005 Zulu: January 2006 6.2. Cost of Effort: (Approximate; some overlap exists.) Ashanti: 16 staff for 3 months Zulu: 9 staff for 5 months 6.3. Cost of Capital Resources: USD$65K for QE test systems. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: ON and admin/install 6.4.3. Type of CPT Review and Approval expected: Standard 6.4.4. Project Boundary Conditions: TBD 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: None 6.4.7. Target RTI Date/Release: s10u1_15, s10u2 6.4.8. Target Code Design Review Date: Ongoing 6.4.9. Update approval addition: No 6.5. ARC review type: Standard 7. Prototype Availability: 7.1. Prototype Availability: At least 1 month to complete prototype; remainder of schedule in 6.2 to make it production. 7.2. Prototype Cost: As above.