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
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
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
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.