How Zones Work
A non-global zone can be thought of as a box. One or
more applications can run in this box without interacting with the rest of
the system. Solaris zones isolate software applications or services by using flexible, software-defined boundaries.
Applications that are running in the same instance of the Solaris Operating System
can then be managed independently of one other. Thus, different versions of the
same application can be run in different zones, to match the requirements of
A process assigned to a zone can manipulate, monitor, and directly communicate with
other processes that are assigned to the same zone. The process cannot perform
these functions with processes that are assigned to other zones in the system
or with processes that are not assigned to a zone. Processes that are
assigned to different zones are only able to communicate through network APIs.
IP networking can be configured in two different ways, depending on whether the
zone has its own exclusive IP instance or shares the IP layer configuration
and state with the global zone. For more information about IP types in
zones, see Zone Network Interfaces. For configuration information, see How to Configure the Zone.
Every Solaris system contains a global zone. The global zone has a dual function.
The global zone is both the default zone for the system and the
zone used for system-wide administrative control. All processes run in the global zone
if no non-global zones, referred to simply as zones, are created by the
The global zone is the only zone from which a non-global zone
can be configured, installed, managed, or uninstalled. Only the global zone is bootable from
the system hardware. Administration of the system infrastructure, such as physical devices, routing
in a shared-IP zone, or dynamic reconfiguration (DR), is only possible in the
global zone. Appropriately privileged processes running in the global zone can access objects
associated with other zones.
Unprivileged processes in the global zone might be able to perform operations not
allowed to privileged processes in a non-global zone. For example, users in the
global zone can view information about every process in the system. If this
capability presents a problem for your site, you can restrict access to the
Each zone, including the global zone, is assigned a zone name. The global
zone always has the name global. Each zone is also given a unique
numeric identifier, which is assigned by the system when the zone is booted.
The global zone is always mapped to ID 0. Zone names
and numeric IDs are discussed in Using the zonecfg Command.
Each zone also has a node name that is completely independent of
the zone name. The node name is assigned by the administrator of the
zone. For more information, see Non-Global Zone Node Name.
Each zone has a path to its root directory that is relative
to the global zone's root directory. For more information, see Using the zonecfg Command.
The scheduling class for a non-global zone is set to the scheduling class
for the system by default. See Scheduling Class for a discussion of methods used
to set the scheduling class in a zone.
Summary of Zone Features
The following table summarizes the characteristics of global and non-global zones.
Type of Zone
Is assigned ID 0 by the system
Provides the single instance of the Solaris kernel that is bootable and running on the system
Contains a complete installation of the Solaris system software packages
Can contain additional software packages or additional software, directories, files, and other data not installed through packages
Provides a complete and consistent product database that contains information about all software components installed in the global zone
Holds configuration information specific to the global zone only, such as the global zone host name and file system table
Is the only zone that is aware of all devices and all file systems
Is the only zone with knowledge of non-global zone existence and configuration
Is the only zone from which a non-global zone can be configured, installed, managed, or uninstalled
Is assigned a zone ID by the system when the zone is booted
Shares operation under the Solaris kernel booted from the global zone
Contains an installed subset of the complete Solaris Operating System software packages
Contains Solaris software packages shared from the global zone
Can contain additional installed software packages not shared from the global zone
Can contain additional software, directories, files, and other data created on the non-global zone that are not installed through packages or shared from the global zone
Has a complete and consistent product database that contains information about all software components installed on the zone, whether present on the non-global zone or shared read-only from the global zone
Is not aware of the existence of any other zones
Cannot install, manage, or uninstall other zones, including itself
Has configuration information specific to that non-global zone only, such as the non-global zone host name and file system table
Can have its own time zone setting
How Non-Global Zones Are Administered
A global administrator has superuser privileges or the Primary Administrator role. When logged
in to the global zone, the global administrator can monitor and control the
system as a whole.
A non-global zone can be administered by a zone administrator. The global administrator assigns
the Zone Management profile to the zone administrator. The privileges of a zone
administrator are confined to a non-global zone.
How Non-Global Zones Are Created
The global administrator uses the zonecfg command to configure a zone by specifying
various parameters for the zone's virtual platform and application environment. The zone is
then installed by the global administrator, who uses the zone administration command zoneadm
to install software at the package level into the file system hierarchy established for
the zone. The zoneadm command is used to boot the zone. The global
administrator can then log in to the installed zone by using the
zlogin command. At first login, the internal configuration for the zone is completed.
For information about zone configuration, see Chapter 17, Non-Global Zone Configuration (Overview). For information about zone installation,
see Chapter 19, About Installing, Halting, Cloning, and Uninstalling Non-Global Zones (Overview). For information about zone login, see Chapter 21, Non-Global Zone Login (Overview).
Non-Global Zone State Model
A non-global zone can be in one of the following six states:
The zone's configuration is complete and committed to stable storage. However, those elements of the zone's application environment that must be specified after initial boot are not yet present.
During an install or uninstall operation, zoneadm sets the state of the target zone to incomplete. Upon successful completion of the operation, the state is set to the correct state.
A damaged installed zone can be marked incomplete by using the mark subcommand of zoneadm. Zones in the incomplete state are shown in the output of zoneadm list -iv.
The zone's configuration is instantiated on the system. The zoneadm command is used to verify that the configuration can be successfully used on the designated Solaris system. Packages are installed under the zone's root path. In this state, the zone has no associated virtual platform.
The virtual platform for the zone is established. The kernel creates the zsched process, network interfaces are set up and made available to the zone, file systems are mounted, and devices are configured. A unique zone ID is assigned by the system. At this stage, no processes associated with the zone have been started.
User processes associated with the zone application environment are running. The zone enters the running state as soon as the first user process associated with the application environment (init) is created.
- Shutting down and Down
These states are transitional states that are visible while the zone is being halted. However, a zone that is unable to shut down for any reason will stop in one of these states.
Chapter 20, Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks) and the zoneadm(1M) man page describe how to use the zoneadm command
to initiate transitions between these states.
Table 16-1 Commands That Affect Zone State
Current Zone State
zonecfg -z zonename verify
zonecfg -z zonename delete
zoneadm -z zonename attach
zoneadm -z zonename verify
zoneadm -z zonename clone
You can also use zonecfg to rename a
zone in the configured or installed state.
zoneadm -z zonename uninstall
zoneadm -z zonename ready
zoneadm -z zonename boot
zoneadm -z zonename uninstall uninstalls the configuration of the
specified zone from the system.
zoneadm -z zonename move path
zoneadm -z zonename detach
-z zonename can be used to add or remove an attr, bootargs, capped-memory,
dataset, capped-cpu, dedicated-cpu, device, fs, ip-type, limitpriv, net, rctl, or scheduling-class property.
You can also rename a zone in the installed state. The inherit-pkg-dir resources cannot
zoneadm -z zonename boot
zoneadm halt and system reboot return a zone in
the ready state to the installed state.
zonecfg -z zonename can be used to
add or remove attr, bootargs, capped-memory, dataset, capped-cpu, dedicated-cpu, device, fs, ip-type,
limitpriv, net, rctl, or scheduling-class property. The inherit-pkg-dir resources cannot be changed.
zoneadm -z zonename reboot
zoneadm -z zonename halt returns a ready zone to
the installed state.
zoneadm halt and system reboot return a zone in the running
state to the installed state.
zonecfg -z zonename can be used to add or
remove an attr, bootargs, capped-memory, dataset, capped-cpu, dedicated-cpu, device, fs, ip-type, limitpriv,
net, rctl, or scheduling-class property. The zonepath and inherit-pkg-dir resources cannot be changed.
Note - Parameters changed through zonecfg do not affect a running zone. The zone must
be rebooted for the changes to take effect.
Non-Global Zone Characteristics
A zone provides isolation at almost any level of granularity you require. A
zone does not need a dedicated CPU, a physical device, or a
portion of physical memory. These resources can either be multiplexed across a number
of zones running within a single domain or system, or allocated on a
per-zone basis using the resource management features available in the operating system.
Each zone can provide a customized set of services. To enforce basic process
isolation, a process can see or signal only those processes that exist in
the same zone. Basic communication between zones is accomplished by giving each zone
IP network connectivity. An application running in one zone cannot observe the network
traffic of another zone. This isolation is maintained even though the respective streams
of packets travel through the same physical interface.
Each zone is given a portion of the file system hierarchy. Because
each zone is confined to its subtree of the file system hierarchy, a
workload running in a particular zone cannot access the on-disk data
of another workload running in a different zone.
Files used by naming services reside within a zone's own root file
system view. Thus, naming services in different zones are isolated from one other and
the services can be configured differently.
Using Resource Management Features With Non-Global Zones
If you use resource management features, you should align the boundaries of the
resource management controls with those of the zones. This alignment creates a more
complete model of a virtual machine, where namespace access, security isolation, and resource
usage are all controlled.
Any special requirements for using the various resource management features with zones are
addressed in the individual chapters of this manual that document those features.