Technical description for BE management. 1. Technical Description: 1.1 BE definition: Snap Boot Environment (BE) Management provides the mechanism to safely update software by capturing system states and allowing previous system states to be re-enabled. It does this by creating a clone of the 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 (e.g. /usr, /var). The root file system and all other file systems of the BE which contain system software must be zfs datasets. 1.2 BE ZFS dataset layout: Boot Environments (BE) are encapsulated within the container dataset namespace described in PSARC case 2006/370. A BE's datasets will be contained within /ROOT/ and any subordinate datasets for that BE will be found within that hierarchy. We depend on zfs boot's process of mounting all the subordinate datasets under a BE's root dataset when a BE is booting up. For example: /ROOT/myBE mounted as / /ROOT/myBE/usr mounted as /usr /ROOT/myBE/var mounted as /var /ROOT/myBE/opt mounted as /opt Datasets that reside outside the designated /ROOT area are "shared" across all BEs. These are seen and mounted identically by a BE regardless of which BE is currently booted. These would be file systems that are not considered system file systems and would be things like /export. For example: rpool/export mounted as /export rpool/export/home mounted as /export/home These shared datasets are not normally mounted when a BE is mounted. The root dataset for a BE will have its mountpoint property set to /, however, legacy mounted roots are still supported because the initial release of OpenSolaris (2008.05) did not have support for non-legacy mounted zfs roots yet and we continue to support those environments as valid BEs. In addition, we also support the scenario where subordinate datasets of a BE are set to be legacy mounted. For these reasons, we consult the BE's vfstab when mounting/unmounting a BE, and modify it accordingly when creating copies of BEs that have legacy mounts. 1.3 Zones support and dataset layout: Support for zones will be limited to zones that support pkg(5). Branded zones that do not support pkg(5) or are not tied to the current BE's OS version, such as Linux branded zones, are not managed at all and are shared between BEs without any changes. For Solaris zones, only installed or running zones are copied into a new BE. zones datasets will use a similar name space scheme for their datasets. The name space for zones will use the following pattern: //ROOT/ A zone and its datasets are associated to a global zone BE through the uuid of the global zone. This uuid is attached to the zone's datasets using a user property. Since the uuid of a global zone BE never changes this association survives a BE rename. When a global zone BE is created based on a BE with non-global zones these zones are clone/copied into the new BE. This is done by cloning the non-global zone's datasets and then setting the parent BE user property of the new datasets to match the uuid of the new BE. The new zone dataset that is created will have the same layout as the original but the zone BE name will be incremented. For example the dataset would follow this pattern: //ROOT/- (or rpool/export/zones/zone1/ROOT/zbe-1) The ability to create BEs inside a zone will also be supported with the ability to run beadm inside a non-global zone. When a zone BE is created its datasets are cloned/copied and the parentbe and active properties are set. The parentbe property will be the same as the dataset copied but the active user property will be set to "off" initially and only set to "on" when it is activated. With the parentbe user property set to "on", the next time this zone is booted this dataset will be what is booted. A more detailed description of zones support is available at: http://opensolaris.org/os/project/caiman/Snap_Upgrade/snap-documents/Snap_zones_layout.pdf 1.4 BE Metadata: The metadata for BE's and zones datasets are attached to the BE's datasets using user properties. These properties produce a unique identifier for the BE, its clean-up rules, the parent BE a zone dataset belongs to and which zone dataset belongs to the active zone dataset for that zone and parent BE. - org.opensolaris.libbe:uuid - A unique identifier that is maintained across renames and is used not only to identify the BE but is also used to determine which zone datasets belong to this BE. - org.opensolaris.libbe:policy - Identifies what set of rules will determine if and when this BE will be cleaned up. - org.opensolaris.libbe:parentbe - This is used by zones datasets to determine which BE the zone belongs to. It is set to the uuid of the parent BE. - org.opensolaris.libbe:active - This determines which zone root dataset is the active dataset for the zone and which will be used when the zone is booted. 1.5 GRUB menu and SPARC boot menu management: The following actions are provided for managing the boot/GRUB menus. o adding entries - The entry for the BE being cloned/copied is copied for the new BE - only title and bootfs lines are manipulated. - For x86/64 find_root will be used to determine which BE to boot, when support for find_root becomes available for use with ZFS boot. o removing entries - removes the entries with a bootfs line that matches the BE being destroyed. o changing entries - as with adding an entry only the BE name in the title and bootfs lines are changed. o setting the default entry (for x86/64 only) o rebuilding menu.lst if its found to be missing (for both SPARC and x86/64). - If the menu.lst file is missing a very minimal menu.lst file will be generated based on the BEs found on the system. 1.6 GRUB Capability version: The GRUB capability version is defined in the capability file delivered with grub. BE management consumes the VERSION field within this file to determine if the currently install version is older than that in the newly updated BE. If a newer version is needed installgrub will be run to update GRUB. The capability file on the system is then updated to reflect the new capability version. 1.7 beadm sub-command interfaces: beadm CLI subcommands: list - Lists the BE's on the system and the data about the BE. create - Creates a new BE or a snapshot of a BE. This snapshot can later be used to create a new BE. destroy - Destroys a BE mount - Mounts the BE and all of its filesystems. Shared filesystems are not normally mounted unless the user specifies that they should be. In the case of zones the shared filesystems for the zones are mounted. umount/unmount - Unmounts the BE and all of its filesystems. rename - Renames the BE activate - Makes this the BE that will be the default at the next reboot.