Jerry Jelinek's blog

Close this search box.

Month: December 2008

In my
last post
I talked a bit about the new way that software and dataset management works for
zones on the

One of the features that is still under development is to provide
a way to automatically keep the non-global zones in sync with
the global zone when you do a ‘pkg image-update’. The
project still needs some additional enhancements to be
able to describe the software dependencies between the
global and non-global zones. In the meantime, you must
manually ensure that you update the non-global zones after
you do an image-update and reboot the global zone. Doing
this will create new ZFS datasets for each zone which you can
then manually update so that they match the global zone software

The easiest way to update the zones is to use the new detach/attach
capabilities we added to the 2008.11 release. You can simply detach
the zone, then re-attach it. We provide some support for the zone
update on attach
option for ipkg-branded zones, so you can use ‘attach -u’ to simply update
the zone.

The following shows an example of this.

# zoneadm -z jj1 detach
# zoneadm -z jj1 attach -u
Global zone version: pkg:/entire@0.5.11,5.11-0.101:20081119T235706Z
Non-Global zone version: pkg:/entire@0.5.11,5.11-0.98:20080917T010824Z
Updating non-global zone: Output follows
Cache: Using /var/pkg/download.
PHASE                                          ITEMS
Indexing Packages                        54/54
DOWNLOAD                                    PKGS           FILES       XFER (MB)
Completed                                     54/54   2491/2491   52.76/52.76
PHASE                                        ACTIONS
Removal Phase                            1253/1253
Install Phase                                 1440/1440
Update Phase                               3759/3759
Reading Existing Index                            9/9
Indexing Packages                               54/54

Here you can see how the zone is updated when it is re-attached to the
system. This updates the software in the currently active dataset associated with
the global zone BE. If you roll-back to an earlier image, the dataset associated
with the zone and the earlier BE will be used instead of this newly updated dataset.
We’ve also enhanced the IPS code so it can use the pkg cache from the global
zone, thus the zone update is very quick.

Because the zone attach feature is implemented as a brand-specific capability,
each brand provides its own options for how zones can be attached. In addition
to the -u option, the ipkg brand supports a -a or -r option. The -a option allows
you to take an archive (cpio, bzip2, gzip, or USTAR tar) of a zone from another
system and attach it. The -r option allows you to receive the output of a ‘zfs send’
into the zone’s dataset. Either of these options can be combined with -u to
enable zone migration from one OpenSolaris system to another. An additional
option, which didn’t make it into 2008.11, but is in the development release, is
the -d option, which allows you to specify an existing dataset to be used for the
attach. The attach operation will take that dataset and add all of the properties
needed to make it usable on the current global zone BE.

If you used zones on 2008.11, you might have noticed that the zone’s dataset
is not mounted when the zone is halted. This is something we might change in
the future, but in the meantime, one final feature related to zone detach is that it
leaves the zone’s dataset mounted. This provides and easy way to access the zone’s
data. Simply detach the zone, then you can access the zone’s mounted file system,
then re-attach the zone.

OpenSolaris 2008.11
release just came out and we’ve made
some significant changes in the way that zones are installed
on this release. The motivation for these changes are so that we
can eventually have software management operations using
work in a non-global zone much the same way as they work
in the global zone. Global zone software management
uses the
SNAP Upgrade
project along with IPS and the idea is to create a new Boot
Environment (BE) when you update the software in the global
zone. A BE is based on a ZFS snapshot and clone, so that you
can easily roll back if there are any problems with the newly
installed software. Because the software in the non-global zones
should be in sync with the global zone, when a new BE is created
each of the non-global zones must also have a new ZFS snapshot and
clone that matches up to the new BE.

We’d also eventually like to have the same software management capabilities
within a non-global zone. That is, we’d like the non-global zone
system administrator to be able to use IPS to install software in
the zone, and as part of this process, a new BE inside the zone would
be created based on a ZFS snapshot and clone. This way the
non-global zone can take advantage of the same safety features for
rolling back that are available in the global zone.

In order to provide these capabilities, we needed to make some
important changes in how zones are laid out in the file system.
To support all of this we need the actual zone root file system
to be its own delegated ZFS dataset. In this way the non-global zone
sysadmin can make their own ZFS snapshots and clones of the zone root
and the IPS software can automatically create a new BE within the zone
when a software management operation takes place in the zone.

The gory details of this are discussed in

All of the capabilities described above don’t work yet, but we have laid
a foundation to enable this for the future. In particular, when you create
a new global zone BE, all of the non-global zones are also cloned as well.
However, running image-update in the global zone still doesn’t update each
individual zone. You still need to do that manually, as Dan described
in his
about zones on the 2008.05 release. In a future post I’ll talk about some other ways
to update each zone. Another feature that isn’t done yet is the full
SNAP Upgrade support from within the zone itself. That is, zone roots
are now delegated ZFS datasets, but when you run IPS inside the zone itself,
a new clone is not automatically created. Adding this feature should be fairly
straightforward though, now that the basic support is in the release.

With all of these changes to how zone roots use ZFS in 2008.11, here is
a summary of the important differences and limitations with using zones
on 2008.11.

1) Existing zones can’t be used. If you have zones
installed on an earlier release of OpenSolaris and image-update to 2008.11 or
later, those zones won’t be usable.

2) Your global zone BE needs a UUID. If you are running 2008.11 or later
then your global zone BE will have a UUID.

3) Zones are only supported in ZFS. This means that the zonepath
must be a dataset. For example, if the zonepath for your
zone is /export/zones/foo, then /export/zones must be a dataset.
The zones code will then create the foo dataset and all the
underlying datasets when you install the zone.

4) As I mentioned above, image-updating the global BE doesn’t update
the zones yet. After you image-update the global zone, don’t forget to
update the new BE for each zone so that it is in sync with the global zone.

Recent Posts

September 23, 2010
September 13, 2010
May 26, 2009