System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones

Chapter 16 Introduction to Solaris Zones

The Solaris Zones facility in the Solaris Operating System provides an isolated environment in which to run applications on your system. Solaris Zones are a component of the Solaris Container environment.

This chapter covers the following topics:

If you are ready to start creating zones on your system, skip to Chapter 17, Non-Global Zone Configuration (Overview).

Zones Overview

The Solaris Zones partitioning technology is used to virtualize operating system services and provide an isolated and secure environment for running applications. A zone is a virtualized operating system environment created within a single instance of the Solaris Operating System. When you create a zone, you produce an application execution environment in which processes are isolated from the rest of the system. This isolation prevents processes that are running in one zone from monitoring or affecting processes that are running in other zones. Even a process running with superuser credentials cannot view or affect activity in other zones.

A zone also provides an abstract layer that separates applications from the physical attributes of the machine on which they are deployed. Examples of these attributes include physical device paths.

Zones can be used on any machine that is running at least the Solaris 10 release. The upper limit for the number of zones on a system is 8192. The number of zones that can be effectively hosted on a single system is determined by the total resource requirements of the application software running in all of the zones.

In the Solaris 10 release, there are two types of non-global zone root file system models: sparse and whole root. The sparse root zone model optimizes the sharing of objects. The whole root zone model provides the maximum configurability. These concepts are discussed in Chapter 18, Planning and Configuring Non-Global Zones (Tasks).

Solaris 10 9/10: Products that are installed, called system assets, are controlled by an Auto Registration feature. During installation, the user provides credentials or registers anonymously. When the system reboots, service tags for the new products are uploaded to the My Oracle Support server. This feature only works in the global zone. See System Administration Guide: Basic Administration for more information.

About Branded Zones

Branded zones (BrandZ) provide the framework to create containers that contain alternative sets of runtime behaviors. Brand can refer to a wide range of operating environments. For example, the non-global zone can emulate the Solaris 8 Operating System, or an operating environment such as Linux.

The brand defines the operating environment that can be installed in the zone and determines how the system will behave within the zone so that the software installed in the zone functions correctly. In addition, a zone's brand is used to identify the correct application type at application launch time. All branded zone management is performed through extensions to the standard zones commands. Most administration procedures are identical for all zones.

The following two brands are supported on SPARC machines running the Solaris 10 8/07 Operating System or later Solaris 10 release:

The solaris8 brand, Solaris 8 Containers, documented in System Administration Guide: Oracle Solaris 8 Containers
The solaris9 brand, Solaris 9 Containers, documented in System Administration Guide: Oracle Solaris 9 Containers

Other brands supported on the Solaris 10 OS include:

The Linux lx brand for x86 and x64 systems, documented in Part III, lx Branded Zones
The cluster brand, documented in the Sun Cluster 3.2 1/09 Software Collection for Solaris OS on docs.sun.com

Although you can configure and install branded zones on a Trusted Solaris system that has labels enabled, you cannot boot branded zones on this system configuration.

When to Use Zones

Zones are ideal for environments that consolidate a number of applications on a single server. The cost and complexity of managing numerous machines make it advantageous to consolidate several applications on larger, more scalable servers.

The following figure shows a system with four zones. Each of the zones apps, users, and work is running a workload unrelated to the workloads of the other zones, in a sample consolidated environment. This example illustrates that different versions of the same application can be run without negative consequences in different zones, to match the consolidation requirements. Each zone can provide a customized set of services.

Figure 16–1 Zones Server Consolidation Example

Different versions of same application can be run in
different zones without negative consequences.

Zones enable more efficient resource utilization on your system. Dynamic resource reallocation permits unused resources to be shifted to other containers as needed. Fault and security isolation mean that poorly behaved applications do not require a dedicated and under-utilized system. With the use of zones, these applications can be consolidated with other applications.

Zones allow you to delegate some administrative functions while maintaining overall system security.

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 your configuration.

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.

Starting with Solaris 10 8/07, 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 global administrator.

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 global zone.

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 in a Zone for a discussion of methods used to set the scheduling class in a zone.

You can use the priocntl described in the priocntl(1) man page to move running processes into a different scheduling class without changing the default scheduling class and rebooting.

Summary of Zone Features

The following table summarizes the characteristics of global and non-global zones.

Type of Zone	Characteristic
Global	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
Non-Global	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

Type of Zone

Characteristic

Global

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

Non-Global

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 global administrator can log in to the installed zone by using the zlogin command. At first login, the internal configuration for the zone is completed. The zoneadm command is then used to boot the zone.

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:

Configured: 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.
Incomplete: 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.
Installed: 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.
Ready: 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.
Running: 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	Applicable Commands
Configured	`zonecfg` `-z` `zonename` `verify` `zonecfg` `-z` `zonename` `commit` `zonecfg` `-z` `zonename` `delete` `zoneadm` `-z` `zonename` `attach` `zoneadm` `-z` `zonename` `verify` `zoneadm` `-z` `zonename` `install` `zoneadm` `-z` `zonename` `clone` You can also use `zonecfg` to rename a zone in the configured or installed state.
Incomplete	`zoneadm` `-z` `zonename` `uninstall`
Installed	`zoneadm` `-z` `zonename` `ready` (optional) `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` `zonecfg` `-z` `zonename` can be used to add or remove an `attr`, `bootargs`, `capped-memory`, `dataset`, `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 be changed.
Ready	`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 an `attr`, `bootargs`, `capped-memory`, `dataset`, `dedicated-cpu`, `device`, `fs`, `ip-type`, `limitpriv`, `net`, `rctl`, or `scheduling-class` property. The `inherit-pkg-dir` resources cannot be changed.
Running	`zlogin` `options` `zonename` `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`, `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.

Features Provided by Non-Global Zones

Non-global zones provide the following features:

Security

Once a process has been placed in a zone other than the global zone, neither the process nor any of its subsequent children can change zones.

Network services can be run in a zone. By running network services in a zone, you limit the damage possible in the event of a security violation. An intruder who successfully exploits a security flaw in software running within a zone is confined to the restricted set of actions possible within that zone. The privileges available within a zone are a subset of those available in the system as a whole.

Isolation

Zones allow the deployment of multiple applications on the same machine, even if those applications operate in different trust domains, require exclusive access to a global resource, or present difficulties with global configurations. For example, multiple applications running in different shared-IP zones on the same system can bind to the same network port by using the distinct IP addresses associated with each zone or by using the wildcard address. The applications are also prevented from monitoring or intercepting each other's network traffic, file system data, or process activity.

Network Isolation

If a zone needs to be isolated at the IP layer on the network, for example, by being connected to different VLANs or different LANs than the global zone and other non-global zones, then for security reasons the zone can have an exclusive IP. The exclusive-IP zone can be used to consolidate applications that must communicate on different subnets that are on different VLANs or different LANs.

Zones can also be configured as shared-IP zones. These zones connect to the same VLANs or same LANs as the global zone and share the IP routing configuration with the global zone. Shared-IP zones have separate IP addresses, but share the other parts of IP.

Virtualization

Zones provide a virtualized environment that can hide details such as physical devices and the system's primary IP address and host name from applications. The same application environment can be maintained on different physical machines. The virtualized environment allows separate administration of each zone. Actions taken by a zone administrator in a non-global zone do not affect the rest of the system.

Granularity

A zone can provide isolation at almost any level of granularity. See Non-Global Zone Characteristics for more information.

Environment

Zones do not change the environment in which applications execute except when necessary to achieve the goals of security and isolation. Zones do not present a new API or ABI to which applications must be ported. Instead, zones provide the standard Solaris interfaces and application environment, with some restrictions. The restrictions primarily affect applications that attempt to perform privileged operations.

Applications in the global zone run without modification, whether or not additional zones are configured.

Setting Up Zones on Your System (Task Map)

The following table provides a basic overview of the tasks that are involved in setting up zones on your system for the first time.

Task	Description	For Instructions
Identify the applications that you would like to run in zones.	Review the applications running on your system: Determine which applications are critical to your business goals. Assess the system needs of the applications you are running.	Refer to your business goals and to your system documentation if necessary.
Determine how many zones to configure.	Assess: The performance requirements of the applications you intend to run in zones The availability of the recommended 100 MB of free disk space per zone to be installed	See Evaluating the Current System Setup.
Determine whether you will use resource pools with your zone to create a container.	If you are also using resource management features on your system, align the zones with the resource management boundaries. Configure resource pools before you configure zones. Starting with the Solaris 10 8/07 release, note that you can add zone-wide resource controls and pool functionality to a zone quickly by using `zonecfg` properties.	See How to Configure the Zone andChapter 13, Creating and Administering Resource Pools (Tasks).
Perform the preconfiguration tasks.	Determine the zone name and the zone path. Determine whether the zone will be a shared-IP zone or an exclusive-IP zone, and obtain IP addresses or the data-link name. Determine the required file systems and devices for each zone. Determine the scheduling class for the zone. Determine the set of privileges that processes inside the zone should be limited to, if the standard default set is not sufficient. Note that some `zonecfg` settings automatically add privileges. For example, `ip-type=exclusive` automatically adds multiple privileges required to configure and manage network stacks.	For information on the zone name and path, IP types, IP addresses, file systems, devices, scheduling class, and privileges, see Chapter 17, Non-Global Zone Configuration (Overview) and Evaluating the Current System Setup. For a listing of default privileges and privileges that can be configured in a non-global zone, see Privileges in a Non-Global Zone. For information about IP feature availability, see Networking in Shared-IP Non-Global Zones and Solaris 10 8/07: Networking in Exclusive-IP Non-Global Zones.
Develop configurations.	Configure non-global zones.	See Configuring, Verifying, and Committing a Zone and the zonecfg(1M) man page.
As global administrator, verify and install configured zones.	Zones must be verified and installed prior to login.	See Chapter 19, About Installing, Halting, Cloning, and Uninstalling Non-Global Zones (Overview) and Chapter 20, Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks).
As global administrator, log in to each non-global zone using the `zlogin` command with the `-C` or place a `sysidcfg` file in the zone's `/etc` directory.		See Chapter 21, Non-Global Zone Login (Overview) and Chapter 22, Logging In to Non-Global Zones (Tasks).
As global administrator, boot the non-global zone.	Boot each zone to place the zone in the running state.	See Chapter 19, About Installing, Halting, Cloning, and Uninstalling Non-Global Zones (Overview) and Chapter 20, Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks).
Prepare the new zone for production use.	Create user accounts, add additional software, and customize the zone's configuration.	Refer to the documentation you use to set up a newly installed machine. Special considerations applicable to the zones environment are covered in this guide.