Sun Microsystems Systems Architecture Committee _________________________________________________________________ Subject: SNAP BE Management Submitted by: Evan Layton File: PSARC/2010/059/opinion.txt Date: March 3, 2010 Committee: Mark Carlson (opinion written by Jim Walker), John Fischer, Garrett D'Amore, Glenn Skinner, Gary Winiger, Rick Matthews Product Approval Committee: Systems PAC solaris-pac-opinion@sun.com 1. Summary Snap Boot Environment (BE) Management provides the mechanism to safely update system software by capturing system states and allowing previous system states to be re-enabled. It does this by creating a ZFS clone of the current system. The definition of a boot environment (also called a BE) is an instance of a bootable OpenSolaris environment consisting of a root file system and, optionally, other file systems mounted underneath it. The root file system and all other file systems of the BE which contain system software must be zfs datasets. This project will allow a user to very quickly create a duplicate image of their running system or other inactive BE, which can then be updated and booted. This project will also EOL Live Upgrade in Solaris Next as part of this case. Specifically, PSARC/1997/318 and its exported interfaces will be obsoleted for Solaris Next. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a Minor release of Solaris. This case sets a precedent as the first PSARC case that includes functionality that only works on a ZFS root file system (see section 4.1). 3. Interfaces 3.1 SNAP BE Management Interfaces Exported Interfaces Interface Name Classification Comments --------------------- -------------------- -------------------------- be_init Consolidation Private See [1] be_mount Consolidation Private See [1] be_unmount Consolidation Private See [1] be_create Consolidation Private See [1] be_destroy Consolidation Private See [1] be_rename Consolidation Private See [1] be_activate Consolidation Private See [1] be_create_snapshot Consolidation Private See [1] be_destroy_snapshot Consolidation Private See [1] be_rollback Consolidation Private See [1] be_list Consolidation Private See [1] be_free_list Consolidation Private See [1] beadm list Committed See [2] beadm create Committed See [2] beadm destroy Committed See [2] beadm mount Committed See [2] beadm unmount/umount Committed See [2] beadm rename Committed See [2] beadm activate Committed See [2] [1] system/library/install package [2] install/beadm package Imported Interfaces Interface Name Classification Comments --------------------- -------------------- -------------------------- libinstzones Uncommitted package/svr4 pkg libzfs Contract Private system/file-system/zfs pkg installgrub Uncommitted SUNWcs pkg 3.2 Live Upgrade Interfaces Exported Interfaces Interface Name Classification Comments --------------------- -------------------- -------------------------- lu Obsolete [1] luactivate Obsolete [1] lucancel Obsolete [1] lucompare Obsolete [1] lucreate Obsolete [1] lucurr Obsolete [1] ludelete Obsolete [1] ludesc Obsolete [2] lufslist Obsolete [1] lumake Obsolete [1] lumount Obsolete [1] lurename Obsolete [1] lustatus Obsolete [1] luumount Obsolete [1] luupgrade Obsolete [1] /etc/lutab Obsolete [1] /etc/default/lu Obsolete [3] /etc/lu/synclist Obsolete [3] [1] PSARC/1997/318 [2] PSARC/2001/551 [3] PSARC/2002/064 See Appendix C for imported and private interface detail. 4. Opinion 4.1 ZFS Root File System Required The committee discussed various precedent setting and dependency implications regarding requiring a ZFS Root file system. The committee noted that this is the first case that includes functionality that only works on a ZFS Root file system, which sets a new precedent. However, this case is not dependent on a new case which ONLY allows ZFS Root file systems. 4.2 EOL of Live Upgrade There is no upgrade path between Solaris Nevada which uses Live Upgrade and Solaris Next which uses 'pkg image-update' in conjunction with beadm. The committee noted that additional case work is needed to close the gap between the upgrade approach used by Solaris 10 and Solaris Nevada and Solaris Next. The project team agreed to file RFEs to EOL Live Upgrade in Solaris Next as part of this case. Specifically, PSARC/1997/318 and its exported interfaces will be obsoleted for Solaris Next. In addition, the project team notes that P2V into a Solaris 10 Container (PSARC/2009/253) will be the primary recommended and supported path for migrating from Solaris 10 to Solaris Next, and they plan to provide additional migration aids. 4.3 EOL of UFS as Root File System and ZFS Standards Conformance After committee discussion, it was determined that a project needs to be funded to address standards conformance issues related to using ZFS as a root file system and to EOL UFS as a root file system. 5. Minority Opinion(s) None. 6. Advisory Information The project team is advised to file appropriate RFEs to EOL Live Upgrade in Solaris Next. Specifically, PSARC/1997/318 and its exported interfaces should be Obsoleted. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material PSARC/2010/059/final.materials/* Migration cases: PSARC/2009/253 S10C Live Upgrade cases: PSARC/1997/318 Solaris/NCR Online Upgrade (VM&F/LiveUpgrade) PSARC/2001/084 Live Upgrade Enhancements PSARC/2001/551 Live Upgrade Enhancements PSARC/2002/064 Live Upgrade Boot Environment Enhancements PSARC/2010/059 Copyright 2010 Sun Microsystems