Go to main content

Introduction to Oracle® Solaris Zones

Exit Print View

Updated: October 2017
 
 

How Zones Work

One or more applications can run in a zone without interacting with the rest of the system. Zones isolate software applications or services by using flexible, software-defined boundaries. Applications that are running in the same instance of the Oracle Solaris operating system can then be managed independently of each 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.

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. Exclusive-IP is the default type. For more information about IP types in zones, see Zone Network Interfaces in Oracle Solaris Zones Configuration Resources. For zone configuration information, see How to Configure the Zone in Creating and Using Oracle Solaris Zones.

Every Oracle 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 execute in the global zone if no non-global zones, referred to simply as zones, are created by a user with the Zone Security profile.

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 running on a physical system. Appropriately privileged processes running in the global zone can access objects associated with other zones.

In some cases, 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. if you zlogin to a kernel zone, it also reports that it has ID 0, because it is a virtual global zone. Zone names and numeric IDs are discussed in How to Configure the Zone in Creating and Using Oracle Solaris Zones.

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 in Creating and Using Oracle Solaris Zones.

Each zone has a path to its root directory that is relative to the global zone's root directory. For more information, see About Using the zonecfg Command in Oracle Solaris Zones Configuration Resources.

The scheduling class for a non-global zone is set to the scheduling class for the system by default. See Scheduling Class in Oracle Solaris Zones Configuration Resources for a discussion of methods used to set the scheduling class in a zone.

Block device multipathing is handled by scsi_vhci(7D). The form of the lu: storage URI you select for your configuration determines how the configuration is used. For more information about using lu: URIs with multipathing, see the suri(5) man page.