Boot Environments for Solaris 10 Branded Zones
Until recently, Solaris 10 Branded Zones on Solaris 11 suffered one notable regression:
Live Upgrade did not work. The individual packaging and patching tools work correctly, but the ability to upgrade Solaris while the production workload continued running did not exist. A recent Solaris 11 SRU (Solaris 11.1 SRU 6.4) restored most of that functionality, although with a slightly different concept, different commands, and without all of the feature details. This new method gives you the ability to create and manage multiple boot environments (BEs) for a Solaris 10 Branded Zone, and modify the active or any inactive BE, and to do so while the production workload continues to run.
Background
In case you are new to Solaris: Solaris includes a set of features that enables you to create a bootable Solaris image, called a Boot Environment (BE). This newly created image can be modified while the original BE is still running your workload(s). There are many benefits, including improved uptime and the ability to reboot into (or downgrade to) an older BE if a newer one has a problem.
In Solaris 10 this set of features was named Live Upgrade. Solaris 11 applies the same basic concepts to the new packaging system (IPS) but there isn't a specific name for the feature set. The features are simply part of IPS. Solaris 11 Boot Environments are not discussed in this blog entry.
Although a Solaris 10 system can have multiple BEs, until recently a Solaris 10 Branded Zone (BZ) in
a Solaris 11 system did not have this ability. This limitation was addressed recently, and that enhancement is the subject of this blog entry.
This new implementation uses two concepts. The first is the use of a ZFS clone for each BE. This makes it very easy to create a BE, or many BEs. This is a distinct advantage over the Live Upgrade feature set in Solaris 10, which had a practical limitation of two BEs on a system, when using UFS. The second new concept is a very simple mechanism to indicate the BE that should be booted: a ZFS property. The new ZFS property is named com.oracle.zones.solaris10:activebe (isn't that creative? ).
It's important to note that the property is inherited from the original BE's file system to any BEs you create. In other words, all BEs in one zone have the same value for that property. When the (Solaris 11) global zone boots the Solaris 10 BZ, it boots the BE that has the name that is stored in the activebe property.
Here is a quick summary of the actions you can use to manage these BEs:
To create a BE:
Create a ZFS clone of the zone's root dataset
To activate a BE:
Set the ZFS property of the root dataset to indicate the BE
To add a package or patch to an inactive BE:
Mount the inactive BE
Add packages or patches to it
Unmount the inactive BE
To list the available BEs:
Use the "zfs list" command.
To destroy a BE:
Use the "zfs destroy" command.
Preparation
Before you can use the new features, you will need a Solaris 10 BZ on a Solaris 11 system. You can use these three steps - on a real Solaris 11.1 server or in a VirtualBox guest running Solaris 11.1 - to create a Solaris 10 BZ. The Solaris 11.1 environment must be at SRU 6.4 or newer.
Create a flash archive on the Solaris 10 system
s10# flarcreate -n s10-system /net/zones/archives/s10-system.flar
Configure the Solaris 10 BZ on the Solaris 11 system
s11# zonecfg -z s10z
Use 'create' to begin configuring a new zone.
zonecfg:s10z create -t SYSsolaris10
zonecfg:s10z set zonepath=/zones/s10z
zonecfg:s10z exit
s11# zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / solaris shared
- s10z configured /zones/s10z solaris10 excl
Install the zone from the flash archive
s11# zoneadm -z s10z install -a /net/zones/archives/s10-system.flar -p
You can find more information about the migration of Solaris 10 environments to Solaris 10 Branded Zones in the documentation.
The rest of this blog entry demonstrates the commands you can use to accomplish the aforementioned actions related to BEs.
New features in action
Note that the demonstration of the commands occurs in the Solaris 10 BZ, as indicated by the shell prompt "s10z# ". Many of these commands can be performed in the global zone instead, if you prefer. If you perform them in the global zone, you must change the ZFS file system names.
Create
The only complicated action is the creation of a BE.
In the Solaris 10 BZ, create a new "boot environment" - a ZFS clone. You can assign any name to the final portion of the clone's name, as long as it meets the requirements for a ZFS file system name.
s10z# zfs snapshot rpool/ROOT/zbe-0@snap
s10z# zfs clone -o mountpoint=/ -o canmount=noauto rpool/ROOT/zbe-0@snap rpool/ROOT/newBE
cannot mount 'rpool/ROOT/newBE' on '/': directory is not empty
filesystem successfully created, but not mounted
You can safely ignore that message: we already know that / is not empty! We have merely told ZFS that the default mountpoint for the clone is the root directory.
List the available BEs and active BE
Because each BE is represented by a clone of the rpool/ROOT dataset, listing the BEs is as simple as listing the clones.
s10z# zfs list -r rpool/ROOT
NAME USED AVAIL REFER MOUNTPOINT
rpool/ROOT 3.55G 42.9G 31K legacy
rpool/ROOT/zbe-0 1K 42.9G 3.55G /
rpool/ROOT/newBE 3.55G 42.9G 3.55G /
The output shows that two BEs exist. Their names are "zbe-0" and "newBE".
You can tell Solaris that one particular BE should be used when the zone next boots by using a ZFS property. Its name is com.oracle.zones.solaris10:activebe. The value of that property is the name of the clone that contains the BE that should be booted.
s10z# zfs get com.oracle.zones.solaris10:activebe rpool/ROOT
NAME PROPERTY VALUE SOURCE
rpool/ROOT com.oracle.zones.solaris10:activebe zbe-0 local
Change the active BE
When you want to change the BE that will be booted next time, you can just change the activebe property on the rpool/ROOT dataset.
s10z# zfs get com.oracle.zones.solaris10:activebe rpool/ROOT
NAME PROPERTY VALUE SOURCE
rpool/ROOT com.oracle.zones.solaris10:activebe zbe-0 local
s10z# zfs set com.oracle.zones.solaris10:activebe=newBE rpool/ROOT
s10z# zfs get com.oracle.zones.solaris10:activebe rpool/ROOT
NAME PROPERTY VALUE SOURCE
rpool/ROOT com.oracle.zones.solaris10:activebe newBE local
s10z# shutdown -y -g0 -i6
After the zone has rebooted:
s10z# zfs get com.oracle.zones.solaris10:activebe rpool/ROOT
rpool/ROOT com.oracle.zones.solaris10:activebe newBE local
s10z# zfs mount
rpool/ROOT/newBE /
rpool/export /export
rpool/export/home /export/home
rpool /rpool
Mount the original BE to see that it's still there.
s10z# zfs mount -o mountpoint=/mnt rpool/ROOT/zbe-0
s10z# ls /mnt
Desktop export platform
Documents export.backup.20130607T214951Z proc
S10Flar home rpool
TT_DB kernel sbin
bin lib system
boot lost+found tmp
cdrom mnt usr
dev net var
etc opt
Patch an inactive BE
At this point, you can modify the original BE. If you would prefer to modify the new BE, you can restore the original value to the activebe property and reboot, and then mount the new BE to /mnt (or another empty directory) and modify it.
Let's mount the original BE so we can modify it. (The first command is only needed if you haven't already mounted that BE.)
s10z# zfs mount -o mountpoint=/mnt rpool/ROOT/zbe-0
s10z# patchadd -R /mnt -M /var/sadm/spool 104945-02
Note that the typical usage will be:
Create a BE
Mount the new (inactive) BE
Use the package and patch tools to update the new BE
Unmount the new BE
Reboot
Delete an inactive BE
ZFS clones are children of their parent file systems. In order to destroy the parent, you must first "promote" the child. This reverses the parent-child relationship. (For more information on this, see the documentation.)
The original rpool/ROOT file system is the parent of the clones that you create as BEs. In order to destroy an earlier BE that is that parent of other BEs, you must first promote one of the child BEs to be the ZFS parent. Only then can you destroy the original BE.
Fortunately, this is easier to do than to explain:
s10z# zfs promote rpool/ROOT/newBE
s10z# zfs destroy rpool/ROOT/zbe-0
s10z# zfs list -r rpool/ROOT
NAME USED AVAIL REFER MOUNTPOINT
rpool/ROOT 3.56G 269G 31K legacy
rpool/ROOT/newBE 3.56G 269G 3.55G /
Documentation
This feature is so new, it is not yet described in the Solaris 11 documentation. However, MOS note 1558773.1 offers some details.
Conclusion
With this new feature, you can add and patch packages to boot environments of a Solaris 10 Branded Zone. This ability improves the manageability of these zones, and makes their use more practical. It also means that you can use the existing P2V tools with earlier Solaris 10 updates, and modify the environments after they become Solaris 10 Branded Zones.
