What Are Zones?

Zones are an application and resource management feature of the Solaris 10 operating system. This feature allows the operating system to be represented to applications as virtual operating system environments (zones) that are isolated and secure. These zones provide the advantages of operating system independence with some level of centralized resource management. Hence applications can be isolated from one another by being installed and run in different zones, while at the same time certain operating system resources can be centrally allocated and administered.

From the point of view of an operating system supporting multiple zones, operating system resources include resources such as process management, memory, network configuration, file systems, package registries, user accounts, shared libraries, and, in some cases, installed applications.

Structure of a Multi-zone Environment

A multi-zone environment consists of a global zone (the default operating system) and one or more non-global zones. The global zone contains resources that can be allocated among non-global zones by a global (zone) administrator. Non-global zones provide the following features:

• Security. By running distributed services in non-global zones, you limit the damage possible in the event of a security violation. An intruder who successfully exploits a security flaw in software within one zone is confined to that zone. The privileges available within a non-global zone are a subset of those available in the global zone.

• Runtime isolation. Non-global zones allow for the deployment of multiple applications on the same computer even if those applications require different levels of security, require exclusive access to global resources, or require individualized configuration. For example, multiple applications running in different zones can bind to the same network port by using the distinct IP addresses associated with each non-global zone. The applications are prevented from monitoring or intercepting each others network traffic, file system data, or process activity.

• Administrative isolation. The virtualized operating system environment allows for separate administration of each non-global zone. Actions taken by a zone administrator (as opposed to the global administrator) in a non-global zone, such as creating user accounts, installing and configuring software, and managing processes, do not affect other zones.

There are two types of non-global zones: whole root zones and sparse root zones:

• Whole root zones. Contain a read/write copy of the file system existing on the global zone. When a whole root zone is created, all packages that are installed on the global zone are made available to the whole root zone: a package database is created and all files are copied onto the whole root zone for the dedicated and independent use of the zone.

• Sparse root zones. Contain a read/write copy of only a portion of the file system existing on the global zone (hence the name sparse root) while other file systems are mounted read-only from the global zone as loop-back virtual file systems. When a sparse root zone is created, the global administrator selects which file systems to share with the sparse root zone (by default, the /usr, /lib, /sbin, and /platform directories are shared as read-only file systems). All packages that are installed on the global zone are made available to the sparse root zone: a package database is created and all files in the mounted file system are shared with the zone.

Whole Root Zones vs. Sparse Root Zones

The choice between using whole root non-global zones versus sparse root non-global zones depends upon a trade-off between resource efficiencies and administrative control. Whole root zones allow you to maximize administrative control (independence and isolation) at the cost of memory and other resources, while sparse root zones optimize the efficient sharing of executables and shared libraries (while using a much smaller disk footprint) at the cost of administrative independence. There is currently no measure of the performance advantage of sparse root zones over whole root zones; it is very likely to be software-specific.

Package Propagation

Packages installed in a global zone are (by default) available to all non-global zones: a process called package propagation. (For propagation to take place, newly-created non-global zones must be fully booted, that is, be in a running state.) Propagation provides local (non-global) visibility and availability to packages that are installed in the global zone. Propagation allows for application package life-cycle management (installation, upgrade, un-installation) to be performed centrally by a global administrator, while application configuration and runtime management are performed by (non-global) zones administrators.

For whole root zones, propagation is achieved through the automatic copying of installed files from the global zone to the whole root zones and through automatic synchronization of registry information. For sparse root zones, propagation is achieved through read-only file systems that are shared between the global and sparse root zones and through automatic synchronization of registry information.

Propagation of packages to non-global zones is controlled at the package level using internal package attributes. For some values of these attributes (the default values, at least), propagation can be disabled at install time by using the pkgadd —G option, which overrides the attribute values. Once installed, the propagation behavior of a package cannot be modified, except by uninstalling and reinstalling the package. Patches, for example, cannot change the propagation behavior of a package; in fact, patches must be applied in accordance with the propagation behavior of the package they are upgrading.