Solaris Containers is an implementation of operating system-level virtualization
technology for x86 and SPARC systems, first released publicly in February 2004
in build 51 beta of Solaris 10, and subsequently in the first full release
of Solaris 10, 2005. It is present in illumos distributions, such as
OpenIndiana, SmartOS and OmniOS, as well as in the official Oracle Solaris 11
release. A Solaris Container is the combination
of system resource controls and the boundary separation provided by zones.
Zones act as completely isolated virtual servers within a single operating system
instance. By consolidating multiple sets of application services onto one system
and by placing each into isolated virtual server containers, system
administrators can reduce cost and provide most of the same protections of
separate machines on a single machine. Terminology
The name of this technology changed during development and the pre-launch
public events. Before the launch of Solaris Zones in 2005, a Solaris
Container was any type of workload constrained by Solaris resource
management features. The latter had been a separate software package in earlier
history. By 2007 the term Solaris Containers came to mean a Solaris Zone
combined with resource management controls.
Later, there was a gradual move such that Solaris Containers specifically
referred to non-global zones, with or without additional Resource Management.
Zones hosted by a global zone are known as "non-global zones" but are sometimes
just called "zones". The term "local zone" is specifically discouraged, since
in this usage "local" is not an antonym of "global". The global zone has
visibility of all resource on the system, whether these are associated
with the global zone or a non-global zone. Unless otherwise noted, "zone"
will refer to non-global zones in this article.
To simplify terminology, Oracle dropped the use of the term Container in Solaris
11, and has reverted to use of the term Solaris Zone irrespective of the use of
resource management controls. Description
Each zone has its own node name, access to virtual or physical network
interfaces, and storage assigned to it; there is no requirement for a zone to
have any minimum amount of dedicated hardware other than the disk storage
necessary for its unique configuration. Specifically, it does not require a
dedicated CPU, memory, physical network interface or HBA, although any of these
can be allocated specifically to one zone.
Each zone has a security boundary surrounding it which prevents a process
associated with one zone from interacting with or observing processes
in other zones. Each zone can be configured with its own separate user
list. The system automatically manages user ID conflicts; that is, two zones on
a system could have a user ID 10000 defined, and each would be mapped to its
own unique global identifier. A zone can be in one of the following
states: Configured: configuration was completed
and committed Incomplete: Transition state during
install or uninstall operation Installed: the packages have been
successfully installed Ready: the virtual platform has been
established Running: the zone booted successfully
and is now running Shutting down: the zone is in the
process of shutting down - this is a temporary state, leading to "Down"
Down: the zone has completed the shut down process and is down - this is a
temporary state, leading to "Installed" Some programs cannot be executed from
within a non-global zone; typically this is because the application requires
privileges that cannot be granted within a container. As a zone does not have its
own separate kernel, applications that require direct manipulation of kernel
features, such as the ability to directly read or alter kernel memory
space, may not work inside of a container.
Resources needed Zones induce a very low overhead on CPU
and memory. Most types of zones share the global zone's virtual address space.
A zone can be assigned to a resource pool to guarantee certain usage, or can
be capped at a fixed compute capacity or can be given shares via fair-share
scheduling. Currently a maximum of 8191 non-global
zones can be created within a single operating system instance. "Sparse
Zones", in which most filesystem content is shared with the global zone, can take
as little as 50MB of disk space. "Whole Root Zones", in which each zone has its
own copy of its operating system files, may occupy anywhere from several hundred
megabytes to several gigabytes, depending on installed software. The
8191 limits arises from the limit of 8,192 loopback connections per Solaris
instance. Each zone needs a loopback connection. The global zone gets one,
leaving 8,191 for the non-global zones. Even with Whole Root Zones, disk space
requirements can be negligible if the zone's OS file system is a ZFS clone of
the global zone image, since only the blocks different from a snapshot image
need to be stored on disk; this method also makes it possible to create new
zones in a few seconds. Branded zones
Although all zones on the system share a common kernel, an additional feature set
has been added called branded zones. This allows individual zones to behave
in a manner other than the default brand of the global zone. The existing brands
can be grouped into two categories: brands which do not perform system call
translation: 'native' is the default for Solaris 10
'ipkg' is the default for OpenSolaris, OpenIndiana, and OmniOS
'joyent' is the default for SmartOS 'cluster' is used for Solaris Cluster
zones 'labeled' is used for zones in a Solaris
Trusted Extensions environment brands which perform system call
translation: 'solaris8' provides a Solaris 8
environment on a Solaris 10 system, including translation from Solaris 8
system calls to Solaris 10 system calls 'solaris9' provides a Solaris 9
environment on a Solaris 10 system, including translation from Solaris 9
system calls to Solaris 10 system calls 'lx' provides a Red Hat Enterprise Linux
3 environment on a Solaris 10 system, including translation from RHEL 3 system
calls to Solaris 10 system calls 's10brand' provides a Solaris 10
environment on an OpenSolaris or Oracle Solaris 11 system, including translation
from Solaris 10 system calls to OpenSolaris/Oracle Solaris 11 system
calls 'solaris-kz' provides a separate Solaris
11.2 or newer instance, with its own kernel and independent packages, on an
Oracle Solaris 11.2 or newer system. This feature was first available
publicly in the Solaris 11.2 Beta. The brand for a zone is set at the time
the zone is created. The second category is implemented with interposition points
within the OS kernel that can be used to change the behavior of syscalls, process
loading, thread creation, and other elements.
For the 'lx' brand, libraries from Red Hat 3 or an equivalent distribution such
as CentOS are required to complete the emulated environment.
Documentation The Solaris operating system provides
man pages for Solaris Containers by default; more detailed documentation can
be found at various on-line technical resources.
The first published document and hands-on reference for Solaris Zones was
written in February 2004 by Dennis Clarke at Blastwave.org, providing the
essentials to getting started. This document was greatly expanded upon by
Brendan Gregg in July 2005. The Solaris 8 and Solaris 9 Containers were
documented in detail by Dennis Clarke at Blastwave(tm) again in April 2008 and
this has become a simple How To style guide that can get people started with
Solaris Containers in a production setting. The Blastwave Solaris 8 and
Solaris 9 Containers document was very early in the release cycle of the
Solaris Containers technology and the actions and implementation at Blastwave
resulted in a followup by Sun Microsystems marketing. The book "Oracle
Solaris 10 System Virtualization Essentials" written by Jeff Victor, et
al., offers feature details and best practices. More extensive documentation
may be found at the Oracle documentation site.
Implementation issues As of Solaris 10 10/08, Branded Zones
are supported on the sun4us architecture through packages FJSVs8brandr and
FJSVs9brandr. See also
Operating system-level virtualization Operating system-level virtualization
§ Implementations Comparison of platform virtualization
software Virtual machines
References External links
Documentation for Solaris Zones Document How to Get Started Creating
Oracle Solaris Zones in Oracle Solaris 11
Blogs devoted to Oracle Solaris Zones Jeff Victor's Blog
Mike Gerdts' Blog Moving Solaris 10 Zones
Key patent: US 7437556, "Global visibility controls for operating system
partitions", published 2005-01-27 , and also as EP 1475703