Solaris Containers

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.

Each zone has its own node name, access to virtual or physical network interfaces,[2] 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.[3]

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.[4]

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 (in contrast to a hardware virtual machine), 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.

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 (processor set plus scheduling class) to guarantee certain usage, or can be capped at a fixed compute capacity ("capped CPU") or can be given shares via fair-share scheduling.[5]

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

Although all zones on the system share a common kernel, an additional feature set has been added called branded zones (BrandZ for short). This allows individual zones to behave in a manner other than the default brand of the global zone. The existing brands (October 2009) 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 (available only on SPARC systems)
  • 'solaris9' provides a Solaris 9 environment on a Solaris 10 system, including translation from Solaris 9 system calls to Solaris 10 system calls (available only on SPARC systems)
  • '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 (available only on x86 systems). On SmartOS, lx brand zones can provide a runtime for most modern Linux distributions including Ubuntu, Debian, CentOS, Alpine and others. LX support hasn't been upstreamed to illumos.
  • '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.[6] This feature was first available publicly in the Solaris 11.2 Beta (public download).[7]

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.

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, providing the essentials to getting started. This document was greatly expanded upon by Brendan Gregg in July 2005.[8] The Solaris 8 and Solaris 9 Containers were documented in detail by Dennis Clarke at Blastwave again in April 2008. 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.[9]

As of Solaris 10 10/08, Branded Zones are supported on the sun4us architecture (Fujitsu PRIMEPOWER servers) through packages FJSVs8brandr and FJSVs9brandr.[10]

• Operating system-level virtualization
  • Operating system-level virtualization § Implementations
• Comparison of platform virtualization software
• Virtual machines

• Documentation for Solaris Zones (Containers)
• 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, Tucker, Andrew G.; Beck, John T. & Comay, David S. et al., "Global visibility controls for operating system partitions", published 2004-11-10, assigned to Sun Microsystems Inc., and also as EP 1475703