Go to main content

Introduction to Oracle® Solaris Zones

Exit Print View

Updated: August 2019
 
 

Zone Administration Overview

This section provides an overview of zone administration information for non-global zones.

How Non-Global Zones Are Created

You can specify the configuration and installation of non-global zones as part of an Automated Install (AI) client installation. See Automatically Installing Oracle Solaris 11.4 Systems for more information. Oracle Solaris Zones primarily are created using the direct installation method. Kernel zone creation methods are documented in Installing a Kernel Zone in Creating and Using Oracle Solaris Kernel Zones.

To create a zone on an Oracle Solaris system, 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 zoneadm command is used to boot the zone. The global administrator or authorized user can then log in to the installed zone by using the zlogin command. If role-based access control (RBAC) is in use, the zone administrator must have the authorization solaris.zone.manage/zonename.

How Non-Global Zones Are Administered

Administrators who are assigned the rights to administer the global zone can monitor and control the system as a whole. Limited administrative rights enable a user to administer a non-global zone. This zone administrator is assigned these rights, as described in admin Resource Type in Oracle Solaris Zones Configuration Resources. The rights of a zone administrator are confined to a specific non-global zone.

Non-Global Zone State Model

A non-global zone can be in one of the following 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.

A damaged installed zone can be marked incomplete by using the mark subcommand of zoneadm. Zones in the INCOMPLETE state are shown in the output of the zoneadm list -iv command.

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 Oracle Solaris system. Packages are installed under the zone's root path. In the INSTALLED 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.

UNAVAILABLE

Indicates that the zone is installed, but cannot be verified, made ready, booted, or moved. A zone enters the unavailable state at the following times:

  • When the zone's storage is unavailable and svc:/system/zones:default begins, such as during system boot

  • When the zone's storage is unavailable

  • When archive-based installations fail after successful archive extraction

  • When the zone's software is incompatible with the global zone's software, such as after an improper –F (force) attach

The zoneadm(8) man page describes how to use the zoneadm command to initiate transitions between these states. See also Chapter 11, Troubleshooting Miscellaneous Oracle Solaris Zones Problems in Creating and Using Oracle Solaris Zones.

Auxiliary States for Kernel Zones

In addition to the states available to all non-global zones, Oracle Solaris Kernel Zones have auxiliary states which provide the host system with additional information about the current zone state. Auxiliary states are set during migration, debugging, and kernel maintenance operations.

DEBUGGING

The zone is in the kernel debugger, kmdb. The zone is running, but the zone cannot respond to external events, such as networking. The zlogin command checks for this state and waits until the state is cleared before starting a zlogin session.

MIGRATING-IN

The zone has been booted on the target host and the zone is receiving the live migration image. The zone will be running when migration is complete.

MIGRATING-OUT

The zone is running and being live migrated to another host system.

NO-CONFIG

The zone is known to the system, but its configuration is missing. State of the zone is always INCOMPLETE.

PANICKED

The zone has panicked. The zone cannot respond to external events until it is shut down or rebooted. You must use the console login to log into a zone in this state.

SUSPENDED

When a kernel zone is suspended with the zoneadm suspend command, the zone is in the INSTALLED state with the suspended auxiliary state. In the case of warm migration, the zoneadm detach command clears the suspended auxiliary state on the source system. The zoneadm attach command on the target system brings the zone from CONFIGURED to INSTALLED with the suspended auxiliary state. The zone resumes on the next boot.

For additional information, see Creating and Using Oracle Solaris Kernel Zones and the solaris-kz(7) man page.

Zone States and Zone Commands

The zone state determines which zonecfg, zoneadm, and zlogin commands can be used on the zone.

CONFIGURED
zonecfg -z zonename attach
zonecfg -z zonename clone
zonecfg -z zonename commit
zonecfg -z zonename delete
zonecfg -z zonename install
zonecfg -z zonename mark incomplete
zonecfg -z zonename mark unavailable
zonecfg -z zonename verify

zonecfg -z zonename
   zonecfg:zonename> set zonename=newname
INCOMPLETE
zoneadm -z zonename uninstall
INSTALLED
zoneadm -z zonename boot
zoneadm -z zonename detach
zoneadm -z zonename mark incomplete
zoneadm -z zonename mark unavailable
zoneadm -z zonename migrate rad-uri
zoneadm -z zonename move path
zoneadm -z zonename ready
zoneadm -z zonename rename newname
zoneadm -z zonename uninstall

zonecfg -z zonename
   zonecfg:zonename> add resource-type
   zonecfg:zonename> remove resource-type
READY
zoneadm -z zonename boot

zoneadm halt returns the zone to the INSTALLED state, as does system reboot.

zonecfg -z zonename
   zonecfg:zonename> add resource-type
   zonecfg:zonename> remove resource-type
RUNNING
zlogin options zonename

zoneadm -z zonename migrate -t live rad-uri
zoneadm -z zonename reboot
zoneadm -z shutdown

zoneadm halt returns the zone to the INSTALLED state, as does system reboot.

sysadm evacuate can be used to mass migrate running kernel zones to another host and optionally return them to the original system.

zonecfg -z zonename
   zonecfg:zonename> add resource-type
   zonecfg:zonename> remove resource-type

Note -  If set, the zonepath resource cannot be changed in a running zone.
UNAVAILABLE
zoneadm -z zonename uninstall

zoneadm -z zonename attach changes a zone to the INSTALLED state. If the attachment fails, the zone remains unavailable.

zonecfg -z zonename
   zonecfg:zonename> add resource-type
   zonecfg:zonename> remove resource-type

The add and remove subcommands can be used to change a property or resource that cannot be changed when a zone is in the INSTALLED state.

Non-Global Zone Isolation

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.

Resource Management 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 guide that document those features.

Zones-Related SMF Services

The Service Management Facility (SMF) manages system and application services. For more information, see Managing System Services in Oracle Solaris 11.4.

Zones-related SMF services in the global zone include the following:

svc:/system/zones:default

Starts each zone that has autoboot=true. This service is a zones delegated restarter and provides the ability to prioritize and manage zone booting order. See Zones Delegated Restarter in Creating and Using Oracle Solaris Zonesand the svc.zones(8) and zonecfg(8) man pages.

The zones restarter is notified of the state of the milestone/goals service of each non-global zone that supports it. The milestone/goals service provides an unambiguous point where a system or zone can be considered up and running.

svc:/system/zones-install:default

Performs zone installation on first boot, if needed.

svc:/system/zones-monitoring:default

Controls zonestatd.

svc:/system/zones/zone:zonename

Represents the service instance of a non-global zone named zonename.

svc:/application/pkg/system-repository:default

Caching proxy server that caches pkg data and metadata used during zone installation and other pkg operations. See the pkg(1) and pkg(7) man pages.

svc:/application/pkg/zones-proxyd:default

Used by the packaging system to provide zones access to the system repository.

The svc:/application/pkg/zones-proxy-client:default zones proxy client SMF service runs only in the non-global zone. The service is used by the packaging system to provide zones access to the system repository.

Monitoring Non-Global Zones

To report on the CPU, memory, and resource control utilization of the currently running zones, see Reporting Resource Usage in a Non-Global Zone in Creating and Using Oracle Solaris Zones. The zonestat utility also reports on network bandwidth utilization in exclusive-IP zones. An exclusive-IP zone has its own IP-related state and one or more dedicated data-links.

The fsstat utility can be used to report file operations statistics for non-global zones. See the fsstat(8) man page and Monitoring Non-Global Zones With the fsstat Utility in Creating and Using Oracle Solaris Zones.