Solaris Containers
| Company type | Software feature |
|---|---|
| Industry | Computer software, Virtualization |
| Founded | February 2004 |
| Headquarters | United States |
| Products | Operating system-level virtualization (Solaris Zones) |
| Owner | Oracle Corporation (after acquisition of Sun Microsystems) |
Solaris Containers (also known as Solaris Zones) provide operating system-level virtualization on both x86 and SPARC architectures. Initially introduced in February 2004 as part of the Solaris 10 build 51 beta, they became fully available with Solaris 10 in 2005. These containers are integrated into illumos-based operating systems such as OpenIndiana, SmartOS, Tribblix, OmniOS, and Oracle’s Solaris 11.
A Solaris Container merges resource management features with zones, which serve as isolated virtual servers operating within a single OS instance. This approach lowers the overall cost by enabling multiple application environments to run securely in separate containers on one physical machine, offering isolation comparable to distinct hardware servers.
Terminology
Prior to the 2005 release of Solaris Zones, the term Solaris Container broadly described workloads controlled by Solaris resource management—a feature that was originally offered as a standalone product. By 2007, the definition of Solaris Containers narrowed to specifically describe a Solaris Zone combined with resource management capabilities.
Over time, the phrase "Solaris Containers" evolved to refer predominantly to non-global zones—virtualized environments managed under the global zone—commonly shortened to "zones." The designation "local zone" is discouraged since it does not represent a true opposite to "global." The global zone retains complete visibility and control over system resources. In this context, unless otherwise specified, "zone" denotes non-global zones.
With the release of Solaris 11, Oracle discontinued using "Container," favoring the term "Solaris Zone" regardless of whether resource management features are applied.
Description
Each zone is assigned its own node name, can access either virtual or physical network interfaces, and is allocated specific storage; no dedicated hardware beyond disk space for configuration is necessary. Allocation of dedicated CPUs, memory, physical network adapters, or HBAs is optional and can be configured per zone.
Zones establish a security perimeter that isolates processes and user accounts. To handle user ID conflicts across zones, the system maps identical IDs in different zones to unique global identifiers.
Zones exist in various states:
- Configured: Configuration has been finalized and saved.
- Incomplete: A transitional state during installation or removal.
- Installed: Software packages are fully installed.
- Ready: The virtual environment is set up.
- Running: The zone has booted and is active.
- Shutting down: Temporary phase before transitioning to "Down."
- Down: Zone has been shut down; temporary before returning to "Installed."
Certain applications that need elevated privileges or direct kernel interaction cannot operate inside zones because all zones share the global kernel; unlike hardware virtualization solutions, zones do not provide separate kernels.
Resources needed
Zones introduce minimal overhead on CPU and memory by sharing the global zone’s virtual address space. They can be assigned to resource pools with guaranteed minimum allocations, capped CPU limits, or fair-share scheduling policies.
A single operating system instance can support up to 8,191 non-global zones due to loopback connection limits (8,192 total minus one reserved for the global zone). "Sparse Zones" share most filesystem data with the global zone and may require as little as 50 MB of disk space. Conversely, "Whole Root Zones" maintain independent OS files and consume from hundreds of megabytes up to several gigabytes depending on installed software.
Disk consumption for Whole Root Zones can be reduced significantly by using ZFS clones of the global zone image. This method stores only differences from snapshots and allows new zones to be created in a matter of seconds.
Branded zones
While all zones utilize a shared kernel, branded zones (referred to as BrandZ) allow specific zones to function differently from the global zone’s standard branding. As of October 2009, these brands are divided into two main groups:
- Brands that do not require system call translation:
- 'native' (the default for Solaris 10)
- 'ipkg' (default for OpenSolaris, OpenIndiana, OmniOS)
- 'joyent' (used by SmartOS)
- 'cluster' (designed for Solaris Cluster zones)
- 'labeled' (intended for zones operating within a Solaris Trusted Extensions setup)
- Brands that utilize system call translation:
- 'solaris8' and 'solaris9' offer Solaris 8 and 9 environments on Solaris 10 by translating legacy system calls (available only on SPARC architecture)
- 'lx' provides a Red Hat Enterprise Linux 3 environment on Solaris 10 with syscall translation (x86 architecture only); on SmartOS, it supports runtime environments for newer Linux distributions such as Ubuntu, Debian, CentOS, and Alpine. Note that LX support has not been merged into illumos.
- 's10brand' delivers a Solaris 10 runtime on OpenSolaris or Oracle Solaris 11 through syscall translation
- 'solaris-kz' runs an isolated Solaris 11.2+ instance featuring its own kernel and package set on Oracle Solaris 11.2+ platforms
Zone brands are designated during zone creation. Brands requiring syscall translation achieve this by intercepting kernel calls to adjust system calls, process execution, and thread management.
For the 'lx' brand specifically, it is necessary to include libraries from RHEL 3 or compatible distributions such as CentOS to fully emulate the target environment.
Documentation
Solaris Containers come with built-in man pages, supplemented by a wide range of online technical documentation. Notable early resources include Dennis Clarke’s February 2004 overview at Blastwave and Brendan Gregg’s comprehensive July 2005 tutorial. Clarke also authored in-depth documentation for Solaris 8 and 9 Containers in April 2008. These foundational materials influenced Sun Microsystems’ marketing strategies. The book Oracle Solaris 10 System Virtualization Essentials by Jeff Victor and colleagues provides extensive coverage of features and practical guidance. Additional official documentation can be accessed via Oracle’s documentation portal.
Implementation issues
Starting with Solaris 10 10/08, Branded Zones have been supported on the sun4us architecture (Fujitsu PRIMEPOWER servers) through the installation of packages FJSVs8brandr and FJSVs9brandr.
See also
- Operating system-level virtualization
- Comparison of platform virtualization software
- Virtual machines
External links
- Solaris Zones (Containers) Documentation
- Guide to Creating Oracle Solaris Zones in Oracle Solaris 11
- Blogs covering Oracle Solaris Zones:
- Guide to Moving Solaris 10 Zones
- Relevant patent: , also filed as