This module introduces the Solaris Zones software partitioning technology, a new

feature included in the SolarisTM 10 Operating System (Solaris 10 OS). The Solaris
Zones and Solaris 10 Resource Manager technologies comprise the set of system
management services known as Solaris Containers.

Zones allow application components to be isolated from one another even though
the zones share a single instance of the Solaris Operating System. Resource
management features permit you to allocate the quantity of resources that a
workload receives.

Upon completion of this module, you should be able to:

Identify the features of Solaris Zones

Understand how and why zone partitioning is used
Configure zones
Install zones
Boot zones
Configure resource pools
Configure the zone-wide resource controls
Establish physical memory controls using the resource capping daemon
Administer packages in zones

Solaris
Zones

Introduction Solaris Zones technology enables software partitioning of a

Solaris 10 OS to support multiple virtual independent operating
systems with independent process space, allocated resources, and
users. Zones are ideal for environments that consolidate a number
of applications on a single server. The cost and complexity of
managing numerous machines makes it advantageous to
consolidate several applications on larger, more scalable servers.
When planning to consolidate servers, there are many solutions in
the marketplace. Consumers can choose from three categories of
server consolidation solutions:
 Domains and Partitions - These are consolidation schemes
based on hardware solutions. These include Sun
FireTMDomains and IBM LPARs.
Virtual Machines - These are application-level
consolidation solutions. These include IBM VM and
VMware.
Operating System Partitions - These are operating system-
level solutions. These include FreeBSD Jails and Linux
Vservers

Solaris Zones are in the Operating System Partitions category.

Zones provide virtual operating system services that look like

different Solaris instances to users and applications. This
architecture isolates processes, hides the underlying platform, and
enables administrators to allow the use of system resources on a
granular level. This separation can create a more secure
environment, where multiple applications that previously had to
run on different physical systems can coexist, in different zones,
on one machine.

Solaris Zones allow administrators to dedicate system resources

to individual zones. Each zone maintains its own root password
and user information, separate from other zones and the global
system. Each zone exists with separate process and file system
space, and can only monitor and interact with local processes. A
single processor and single disk system can support several
zones, each with separate resources, users, and process space, as
shown in the image.
 Zones provide separate virtualized operating system
environments that are derived from a single instance of the
Solaris Operating System. Multiple zones can share file systems,
processors, and network interfaces. Allotment of physical
resources to more than one zone allows scaling and sharing of
available resources on an as-needed basis. Individual zones can
gain files and configurations from the global zone.

Solaris Zones

Zone Features Security - Network services can run in a zone, limiting

the potential damage in the event of a security violation.
Processes running within a zone, even one with superuser
credentials, cannot affect activity in other zones. Certain
activities, such as rebooting or shutting down the system
as a whole, are only permitted in the global zone. An
administrator logged in to the global zone can monitor the
activity of applications running in other zones and control
the system as a whole. The global (default) zone is
perpetual.
Isolation - Zones allow you to deploy multiple
applications on the same machine, even if the applications
operate in different trust domains, require exclusive use of
 a global resource, or present difficulties with global
configurations. Individual zones have their own sets of
users and their own root passwords. When you reboot a
zone, other zones running on the system remain
unaffected.
Virtualization - Zones provide virtual environments that
can hide such details as physical devices, the system's
primary internet protocol (IP) address, and host name
from applications. Since the same environment can be
maintained on different physical machines, this can be
useful in supporting rapid deployment and redeployment
of applications.
Granularity - Zones can provide isolation at arbitrary
granularity. A zone does not require a dedicated central
processing unit (CPU), physical device, or chunk of
physical memory. These resources can be multiplexed
across a number of zones running within a single system,
or allocated on a per-zone basis, using resource
management features available in the OS.
Transparency - Except when necessary to achieve
security and isolation, zones avoid changing the
environment in which applications execute. Zones do not
present a new API or application binary interface (ABI) to
which applications must be ported. Instead, they provide
the standard Solaris interfaces and application
environment, with some restrictions on applications
attempting to perform privileged operations.

Zone Concepts

Introduction You must understand the following concepts to understand the

Solaris Zones software partitioning technology:

Zone types
Zone daemons
Zone file systems
Zone networking
Zone states

Zone Concepts
Zone Types The Solaris Operating System supports two types of zones:

Global
Non-global

Zone Concepts

The Global Every Solaris system contains a global zone. The global zone has
Zone two functions: it is both the default zone for the system, and the
zone used for system-wide administrative control. The global
zone is the only zone from which a non-global zone can be
configured, installed, managed, or uninstalled. All processes run
in the global zone if no non-global zones are created.

Only the global zone is bootable from the system hardware.

Administration of the system infrastructure, such as physical
devices, routing, or dynamic reconfiguration (DR), is only
possible in the global zone. The global zone contains a complete
installation of the Solaris system software packages. It can
contain additional software not installed through packages.

The global zone is the only zone from which a non-global zone
can be configured, installed, managed, or uninstalled.
Appropriately privileged processes running in the global zone can
access objects associated with non-global 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.

The global zone provides a complete database that contains

information about all installed components. It holds configuration
information specific to the global zone only, such as the global
zone host name and file system table. The global zone is the only
zone that is aware of all devices and all file systems.

Each zone, including the global zone, is assigned a zone name.

The global zone always uses the name global. Non-global zones
must have user-defined names. The system assigns a unique
 numeric identifier to a zone when the zone boots. The system
always assigns zone ID 0 to the global zone. The system assigns
non-zero zone IDs to non-global zones when they boot. Non-
global zone ID numbers change when you reboot those zones.

Zone Concepts

Non-Global Non-global zones contain an installed subset of the complete

Zones Solaris Operating System software packages. They can also
contain Solaris software packages shared from the global zone
and additional installed software packages not shared from the
global zone. Non-global zones can contain additional software
created within the non-global zone that is not installed through
packages or shared from the global zone.

Non-global zones share operation under the Solaris kernel

booted from the global zone. Non-global zones are not aware
that any other zones exist. A non-global zone cannot install,
manage, or uninstall itself or any other zones.

Zone Concepts

Zone Daemons The system uses two daemons to control zone

operation, zoneadmdand zsched.

The zoneadmd daemon is the primary process for managing the

zone's virtual platform. There is one zoneadmd process running
for each active (ready, running, or shutting down) zone on the
system.

The zoneadmd daemon is responsible for the following activities:

Managing zone booting and shutting down

Allocating the zone ID and starting the zsched system
process
Setting zone-wide resource controls
 Preparing the zone's devices as specified in the zone
configuration
Plumbing virtual network interfaces
Mounting loopback and conventional file systems

Unless it is already running, the zoneadmd daemon is

automatically started by any invocation of
the zoneadm command.

Every active zone has an associated kernel process, zsched.

Thezsched process enables the zones subsystem to keep track of
per-zone kernel threads. Kernel threads doing work on behalf of
the zone are owned by zsched.

Zone Concepts

Zone File There are two models for populating root file system space in
Systems non-global zones, the sparse root model and the whole root
model.

Zone Concepts

Sparse Root The sparse root model installs a minimal number of files from the
Model global zone when you initialize a non-global zone. In this model,
only certain root packages are installed in the non-global zone.
These include a subset of the required root packages that are
normally installed in the global zone, and additional root
packages that the global administrator might have selected. Files
that need to be shared between a non-global zone and the global
zone are mounted through read-only loopback file systems.

By default in the sparse root model, the

directories /lib, /platform,/sbin, and /usr are mounted in this
manner. An example of shared file systems is shown the image.
 After a non-global zone is installed, it is no longer dependent on
the global zone for file access except for data found in the
loopback file systems that the non-global zone uses. If a critical
file is removed from within a non-global zone, only that zone is
affected. If a critical file is removed from the global zone, and the
global zone operating system fails, then each non-global zone
would also fail. If the global operating system did not fail, and
the non-global zone did not need that removed file, the non-
global zone would not be affected.

For files that are mounted using a loopback file system, removing
a critical file from the global zone would have an effect similar to
that in a typical client-server situation. The non-global zone's
dependence on the file would determine how removing the file
would affect the zone.

Zone Concepts

Whole Root The whole root model provides the maximum configurability. All
Model of the required and any selected optional Solaris packages are
installed into the private file systems of the zone. The advantages
of this model include the capability for global zone
administrators to customize their zones file system layout. This
would be done, for example, to add arbitrary unbundled or third-
 party packages. The disk requirements for this model are
determined by the disk space used by the packages currently
installed in the global zone.

Note: Currently, a non-global zone cannot be a Network File System

(NFS) server.

Zone Concepts

Zone Each non-global zone that requires network connectivity has one
Networking or more dedicated IP addresses. These addresses are associated
with logical network interfaces that can be placed in a zone by
using theifconfig command. For example, if the primary
network interface in the global zone is ce0, then the non-global's
logical network interface might be ce0:1. Logical interfaces are
automatically assigned the next available identifier, for
example, ce0:2, ce0:3.

Zone interfaces configured by zonecfg are automatically

plumbed and placed in the zone when it is booted. You can use
the ifconfigcommand to add or remove logical interfaces when
the zone is running. Only the global zone administrator can
modify the interface configuration and the network routes.

You can configure IPMP in the global zone, then extend its
function to non-global zones. You extend this function by placing
the non-global zone's IP address in an IPMP group when you
configure the zone. Then, if one of the interfaces in the global
zone fails, the non-global zone addresses migrate to another
network interface card.

Zone Concepts

Zone To understand how zones operate, we need to understand that zones can
States exist in various states, and what those states mean. Non-global zones
behave like typical Solaris 10 OS installations, but they do not have
resources such as a power-on self-test (POST) or an OpenBoot
Programmable Read-Only Memory (OBP). These resources are
managed by the global zone. As you configure a non-global zone, bring
it into operation, use the zone, reboot, or shut it down, the state that
the zoneadm command reports for that zone changes. The image shows
the zone states.

The zoneadm command reports these zone states:

Undefined - In this state, the zone's configuration has not been

completed and committed to stable storage.
The zoneadmcommand also reports this state when a zone's
configuration has been deleted.
Configured - In this state, 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 - This is a transitional state. 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. However, a zone that is unable to
complete the install process stops in this state.
Installed - In this state, the zone's configuration is in place 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 - In this state, the virtual platform for the zone is
established. The kernel creates the zsched process, network
interfaces are plumbed, 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 - In this state, the user processes associated with the
zone's 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.

Configuring Zones

Introduction Configuring a zone requires completing these tasks:

Identifying the components that will make up the zone

Configuring the zone's resources
Configuring the zone with the zonecfg command
Verifying and committing the configured zone

Configuring Zones

Identifying Zone When planning zones for your environment, you must consider
Components the components that make up each zone's configuration. These
components include:

A zone name
A path to the zone's root
The zone network interfaces
The file systems mounted in zones
The configured devices in zones

Configuring Zones

Configuring System-wide resources, such as CPUs, physical memory, and file

Zone Resources systems, are shared by all zones. Each zone makes its own unique
demands on these resources. Some zones will run lower priority
workloads, some higher priority workloads. You can set limits on
a zone's resource consumption by:

Allocating file system space

 Associating zones with resource pools created on your
system
Configuring zone-wide resource controls
Capping physical memory in each project entry in each
zone

Creating resource pools and capping physical memory for

projects in zones are described later in this module.

Configuring Zones

Allocating File There are no limits on how much disk space can be consumed by
System Space a zone. The global zone administrator is responsible for space
restriction. Even a small uniprocessor system can support a
number of zones running simultaneously. The nature of the
packages installed in the global zone affects the space
requirements of the non-global zones that are created. The
number of packages and space requirements are factors.

As a general guideline, about 100 megabytes of free disk

space per non-global zone is required when the global
zone has been installed with all of the standard Solaris
packages, and the non-global zones have been defined
using the sparse root model.
By default, any additional packages installed in the global
zone also populate the non-global zones. The amount of
disk space required must be increased accordingly. The
directory location in the non-global zone for these
additional packages is specified through the inherit-
pkg-dir resource.

You can place the zone on a loopback file system (LOFS)-

mounted partition. This action limits the amount of space
consumed by the zone to that of the file used by LOFS. You can
also use soft partitions to divide disk slices or logical volumes
into partitions. You can use these partitions as zone roots, and
thus limit per-zone disk consumption. The soft partition limit is
8192 partitions.

An additional 40 megabytes of RAM per zone are suggested, but

not required, on a machine with sufficient swap space.
 Configuring Zones

Assigning Zones A "one zone, one pool" rule applies to non-global zones.
to Resource Processes within a non-global zone are bound only to the pool to
Pools which the non-global zone is bound. Processes within a non-
global zone cannot be bound to other pools. Processes in the
global zone, however, can be bound by a sufficiently privileged
process to any pool.

You use the zonecfg command to associate a zone with a

resource pool on the system. This zonecfg example shows how
to assign a specific pool to a non-global zone:

zonecfg:work-zone> set pool=my-1st-pool

Although a zone can only be associated with one pool, the pool
need not be exclusively assigned to a particular zone.

The resource controller poold only runs in the global zone,

where there is more than one pool for it to operate on.
The poolstat utility run in a non-global zone displays only
information about the pool associated with the zone.
The pooladm command run without arguments in a non-global
zone displays only information about the pool associated with the
zone.

Configuring Zones

Configuring Currently, there are two zone-wide resource controls, zone.max-

Zone-Wide lwps andzone.cpu-shares. Zone-wide resource controls are set
Resource through the zonecfgutility. The zone.cpu-shares resource
Controls control sets the number of Fair Share Scheduler (FSS) CPU
shares assigned to a zone. The CPU shares are first allocated to
the zone, and then further subdivided among projects within the
zone in accordance with each project's project.cpu-
shares entry. The rctlresource type you specify
with zonecfg allows you to set the zone.cpu-sharesparameters.
The parameter names are limit, priv, and action.
 This zonecfg example shows setting the zone.cpu-
shares resource control for a non-global zone:

zonecfg:work-zone> add rctl

zonecfg:work-zone:rctl> set name=zone.cpu-shares
zonecfg:work-zone:rctl> add value
(priv=privileged,limit=20,action=none)
zonecfg:work-zone:rctl> end

The limit value sets the non-global zone's limit of CPU

utilization relative to all zones defined on the system.

Note: Use the following formula to calculate a zone's actual

percentage of CPU allocation:

CPU_allocation_% =
non_global_zone_limit/(non_global_zone_limit +
other_zone_limit...) * 100

You can check a zone's resource controls by running the prctl -

n zone.cpu-shares -i zone zone_name command in the
global zone.

Using the zonecfg Command to Configure

Zones

Introduction The zonecfg command is used to configure zones.

The zonecfgcommand can be used in interactive mode, in
command-line mode, or in command-file mode. The following
operations can be performed using this command:

You can create or delete a zone configuration.

You can add resources to a particular configuration.
You can set properties for resources added to a
configuration.
You can remove resources from a particular
configuration.
You can query or verify a configuration.
You can commit to a configuration.
You can revert to a previous configuration.
You can exit from a zonecfg session.
 Using the zonecfg Command to Configure
Zones

Identifying To simplify the user interface, zonecfg utilizes the concept

thezonecfgCommand of a scope. The default scope is global. You can use
Scope the add and selectsubcommands to select a specific
resource, at which point the scope changes to that resource.
The zonecfg interactive command prompt changes to
reflect the current scope. The end and cancel subcommands
are used to complete the resource specification, at which
time the scope is reverted back to global. Certain
subcommands, such as add, removeand set, have different
semantics in each scope.

Using the zonecfg Command to Configure

Zones

Using zonecfgSubcommands Subcommands within the zonecfg utility are used

to configure and provision zones.
The zonecfg prompt indicates if the scope
is globalor is confined to a particular resource.
Many subcommands also allow the -f, or force,
flag. If this flag is used, the subcommand does not
use interactive questioning safeguards.

The zonecfg Subcommands

Command Description

add Add a resource to the zone.

cancel Exits from resources scope back to

global. Partially specified resources are
abandoned.

commit Verifies settings and commits proper

settings from memory to disk.
 The revert subcommand returns to
this point.

create Create an in-memory configuration for

the specified zone.

delete Delete the configuration from memory.

end Verify that parameters have been

assigned and return to the global scope.

export Print the configuration to stdout, or to

the output file specified, in form that
can be used in a command file.

info Display current configuration for

resource settings or
global zonepath, autoboot, or pool.

remove Removes one or more resource

depending on scope.

select Find a resource whose parameters are

matched within the curly braces and
change to its scope.

set Set an in-memory value for a

parameter.

verify Verify the in-memory configuration. All

resources have required properties
specified and the zonepath is specified
for the zone.

revert Discard any in-memory configurations

and return to the last time
a commit was performed.
 exit Commit current in-memory settings and
exit thezonecfg utility. This command
automatically commits the
configuration information to stable
storage.

Using the zonecfg Command to Configure

Zones

Using zonecfgResource Resource types within the zonecfg utility include the
Parameters following:

zonename - Defines the zone name and identifies

the zone to the configuration utility.
zonepath - Defines the zone path resource and is
the path to the zone root.
autoboot - Determines if the zone will reboot
when the system reboots.
pool - Associates the zone with a specific resource
pool.
fs - Assigns resource parameters for file systems.
Use of thespecial parameter allows the local
zone to mount global system resources under
separate directories. The table shows parameters
associated with the fs resource.

The fs Resource Parameters

dir Specifies the mount point for the file
system
special Specifies the block special device name or
directory from the global zone to mount
raw Specifies the raw device on which to
run fsckbefore mounting the file system
type Specifies the file system type

options Specifies mount options similar to those

found with the mount command
 inherit-pkg-dir - Gives access to software
packages from the global system. The contents of
software packages in theinherit-pkg-
dir directory are inherited by the non-global zone
in read-only mode. The default inherit-pkg-
dir resources are:/lib, /platform, /sbin,
and /usr.

These inherited resources cannot be removed or modified

after the zone has been installed.

net - Provisions logical interfaces of the global

systems interfaces to non-global zones. The
network interfaces are plumbed when the zone
transitions from the installed state to the ready
state.
device - References devices for the select, add,
or removecommands. Each zone can have devices
that should be configured when the zone
transitions from the installed state to the ready
state.
rctl - Configures resource controls with
privileges to modify and assign a resource within a
zone, depending on what the project's resource
allocation might be. Three possible properties are:
o priv
o limit
o action

Refer to the prctl and rctladm man pages for more

information.

attr - Enables the global administrator to assign

generic attribute settings, such as name type and
value. The type must
be int, uint (unsigned), boolean, or string.
Attributes beginning with zone are reserved for
the system.

Using the zonecfg Command to Configure

Zones
Zone To create a zone, you must log in to the global system as root or
Configuration a role based access control (RBAC)-allowed user. The following
Walk-Through shows an example of configuring a zone named work-zone:

Line 1 - This line starts the zonecfg utility in interactive mode.

The zone is called work-zone.

Line 2 - This line begins the in-memory configuration.

Line 3 - The zone path resource, /export/work-zone in this

example, is the path to the zone's root directory. Each zone has a
path to its root directory that is relative to the global zone's root
directory. This path must exist before you install the zone. The
global zone directory,/export in this example, must be owned
by root with the mode 700.

Line 4 - This Boolean indicates that the zone should boot

automatically when the system boots.

Line 5 - This is the name of the resource pool that this zone must
be bound to when booted. The example lists the system default
pool, but you can specify a different pool that you configured for
this zone.

Line 6 - This line begins the file system configuration section in

this procedure, and confines the scope of zonecfg to file system
resources.

Line 7 - This line sets the mount point for the file system, which
is/mnt in this example.

Line 8 - This line specifies that /dev/dsk/c0t0d0s7 is the block

device in the global zone to be mounted as /mnt in work-zone.

Line 9 - This line specifies that /dev/rdsk/c0t0d0s7 is the raw

device to be used for fsck operations. The zoneadmd daemon
automatically runs the fsck command in non-interactive check
only mode on this device before it mounts the file system.

Line 10 - This line specifies that the file system type is UFS.

Line 11 - This line causes the file system to be mounted using

thelogging mount option. Options are specific to file systems.

Line 12 - This line ends the file system configuration section in

this procedure.

Line 13 - This line begins the configuration of a shared file

system that is to be mounted from the global zone as a read-only
loopback mount.

Line 14 - This line specifies that /opt/sfw is to be loopback

mounted from the global zone.

Line 15 - This line ends the loopback mount section in this

procedure.

Line 16 - This line begins the network configuration section in

this procedure.

Line 17 - This line specifies the physical network interface in the

system that this zone will use. A virtual interface will be plumbed
to make use of the physical interface specified, ce0 in this
example.
Line 18 - This line specifies the IP address that the virtual
network interface will use, which is 192.168.0.1 in this
procedure.

Line 19 - This line ends the network configuration section in this

procedure.

Line 20 - This line begins the device configuration section in this

procedure.

Line 21 - This causes the device /dev/sound/* to be configured

when the zone transitions to the ready state.

Line 22 - This line ends the device configuration section in this

procedure.

Line 23 - This line begins the resource control configuration

section in this procedure.

Line 24 - This line sets the name of the resource control, which
iszone.cpu-shares in this procedure.

Line 25 - This line sets the resource control parameter values to:
privileged calls, a limit of 20 CPU shares, and no action to be
taken when that threshold is reached.

Line 26 - This line ends the resource control configuration

section in this procedure.

Line 27 - This line begins the attribute configuration section in

this procedure.

Line 28 - This line sets the name of the name of the attribute,
which iscomment in this procedure.

Line 29 - This line sets the type of attribute as a string of

characters.

Line 30 - This line assigns a value to the string of characters "The

work zone." in this procedure.

Line 31 - This line ends the attribute configuration section in this

procedure.
 Line 32 - This line verifies the current configuration for
correctness. The zonecfg utility ensures that all resources have
all of their required properties specified.

Line 33 - This line commits the current configuration from

memory to stable storage. Until the in-memory configuration is
committed, changes can be removed with
the revert subcommand. A configuration must be committed to
be used by the zoneadmcommand. This operation is attempted
automatically when you complete a zonecfg session. Because
only a correct configuration can be committed,
the commit operation automatically does a verify.

Line 34 - This line exits the zonecfg session. You can use the -
F(force) option with exit.

The zone is now ready to install, boot, and use.

Using the zonecfg Command to Configure

Zones

Viewing the You can use the zonecfg command to view the zone
Zone configuration.
Configuration # zonecfg -z work-zone info
zonepath: /export/work-zone
autoboot: true
pool: pool_default
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
inherit-pkg-dir:
dir: /opt/sfw
fs:
dir: /mnt
special: /dev/dsk/c0t0d0s7
raw: /dev/rdsk/c0t0d0s7
type: ufs
options: [logging]
net:
address: 192.168.0.1
physical: ce0
 device
match: /dev/sound/*
rctl:
name: zone.cpu-shares
value:
(priv=privileged,limit=20,action=none)
attr:
name: comment
type: string
value: "The work zone."
#

Using the zoneadm Command

Introduction The zoneadm command is the primary tool used to install and
administer non-global zones. Operations using
the zoneadm command must be run from the global zone. The
following tasks can be performed using thezoneadm command:

Verify a zone's configuration

Install a zone
Boot a zone
Reboot a zone
Display information about a running zone
Uninstall a zone
Remove a zone using the zonecfg command

Using the zoneadm Command

Verifying a You can verify a zone before you install it. If you skip this
Configured procedure, the verification is performed automatically when you
Zone install the zone. You must be the global administrator in the
global zone to perform this procedure.

You can use the zoneadm -z zone_name verify command to

verify a zone's configuration. For example:

global# zoneadm -z work-zone verify

Warning: /export/work-zone does not exist, so it
cannot be verified. When
zoneadm install is run, install will try to create
/export/work-zone, and
 verify will be tried again, but the verify may fail
if: the parent directory
of /export/work-zone is group- or other-writable or
/export/work-zone overlaps
with any other installed zones.

In this example, a message is displayed warning the administrator

that the zonepath/export/work-zone does not exist.

If an error message is displayed and the zone fails to verify, make

the corrections specified in the message and try the command
again. If no error messages are displayed, you can install the
zone.

Using the zoneadm Command

Installing a You use the zoneadm -z zone_name install command to

Configured install a non-global zone. You must be the global administrator to
Zone perform the zone installation. For example:

global# zoneadm -z work-zone install

Zone installation takes time to complete, depending on the

quantity of data to be copied into the zone's root file system.

You use the zoneadm list -iv command to list the installed
zones and verify the status:

global# zoneadm list -iv

ID NAME STATE PATH
0 global running /
- work-zone installed /export/work-zone

In this example, the work-zone has reached the installed state.

The zone ID is assigned during the zone boot process.

Using the zoneadm Command

Booting a Zone
 Booting a zone places the zone in the running state. If you set
theautoboot resource property in a zone's configuration to true,
that zone automatically boots when the global zone boots. The
default setting isfalse.

You can be manually boot a zone if it is in the ready or installed

state. Use the zoneadm -z zone_name boot command to boot a
zone:

global# zoneadm -z work-zone boot

global# zoneadm list -v
ID NAME STATE PATH
0 global running /
1 work-zone running /export/work-zone

In this example, the work-zone has reached the running state.

The zone ID 1 has been assigned during the zone boot process.

Using the zoneadm Command

Logging In to After you boot the zone for the first time, it is important to
the Zone connect to the zone's virtual console and complete the zone's
Console system identification before you can begin using the zone. To log
in to the zone's virtual console and begin the zone's system
identification process, use the zlogin command with the -
C option.

global# zlogin -C work-zone

The first time that you connect to the zone's virtual console, the
system identification process starts automatically. You are asked
to select a language and locale, and the terminal type. A graphical
user interface (GUI) then starts and presents questions regarding
the zone's host name, Kerberos security, name services, time
zone, root password, and NFS version 4 domain name. When this
identification process completes, the zone automatically reboots.

The ~. (tilde dot) character sequence terminates the console

connection.

Note: To specify an alternate escape character for the console

connection, use zlogin with the -e option. For example, to use the
 caret symbol instead of the tilde symbol (the default), you would
type the following:

zlogin -C -e \^ work-zone

Using the zoneadm Command

Halting a Zone The zoneadm halt command is used to remove both the
application environment and the virtual platform for a zone. The
zone is then brought back to the installed state. All processes are
killed, devices are unconfigured, network interfaces are
unplumbed, file systems are unmounted, and the kernel data
structures are destroyed.

global# zoneadm -z work-zone halt

global# zoneadm list -v
ID NAME STATE PATH
0 global running /
- work-zone installed /export/work-zone

The halt command does not run any shutdown scripts within the
zone.

Using the zoneadm Command

Rebooting a The zoneadm reboot command is used to reboot a zone. The

Zone zone is halted and then booted again.

global# zoneadm -z work-zone reboot

global# zoneadm list -v
ID NAME STATE PATH
0 global running /
2 work-zone running /export/work-zone

Zone IDs are assigned when the non-global zones boot, and
change when they reboot.

Note: The zoneadm halt and reboot subcommands do not shut

down services within the non-global zone using Service Management
 Facility stop methods. Use the init command within the non-global
zone to shut down services in their correct sequence.

Using the zoneadm Command

Logging In to Use the zlogin command to log in to and access non-global

and Working zones from the global zone. To log in to the zone's virtual
With Zones console, use the -C option.

# zlogin -C work-zone
[Connected to zone 'work-zone' console]

After using the console interface to log in to the zone, take a look
at how the operating system views its resources.

twilight# hostname
twilight
twilight# uname -a
SunOS twilight 5.10 s10_54 sun4u sparc SUNW,Netra-
T12
twilight# df -k
File system kbytes used avail
capacity Mounted on
/ 678457 69941 547455 12%
/
/dev 678457 69941 547455 12%
/dev
/lib 33265565 1893804 31039106 6%
/lib
/platform 33265565 1893804 31039106 6%
/platform
/sbin 33265565 1893804 31039106 6%
/sbin
/usr 33265565 1893804 31039106 6%
/usr
proc 0 0 0 0%
/proc
mnttab 0 0 0 0%
/etc/mnttab
fd 0 0 0 0%
/dev/fd
swap 7949040 32 7949008 1%
/var/run
swap 7949008 0 7949008 0%
/tmp
twilight# ps -ef |grep z
 UID PID PPID C STIME TTY TIME
CMD
root 6965 6965 0 12:35:38 ? 0:00
zsched

twilight# ifconfig -a
lo0:1:
flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4>
mtu 8232 index
1 inet 127.0.0.1 netmask ff000000
ce0:1:
flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4>
mtu 1500 index
2 inet 192.168.0.1 netmask ffffff00 broadcast
192.168.0.255

twilight# ~.
[Connection to zone 'work-zone' console closed]
Note: The zone is now up and running. If you add (or delete)
resources to the running zone using the zonecfg command, you
must restart the zone for the changes to take effect.

To remove a resource from a zone, use the zonecfg command.

Use the removesubcommand and identify the resource you wish
to remove. Commit the change and exit the zonecfg command.

# zonecfg -z work-zone
zonecfg:work-zone> remove net physical=ce0
zonecfg:work-zone> commit
zonecfg:work-zone> exit

Using the zoneadm Command

Deleting a Zone When deleting a zone, be sure to back up any files that you want
to keep. The first stage in deleting a zone is halting the Solaris 10
OS and freeing the system memory.

In the following example, the zone is removed from the global

system.

Caution: This operation is not a graceful or controlled shutdown of

the zone. Data loss is possible to processes running in the zone.

# zoneadm list -cp

0:global:running:/
 3:work-zone:running:/export/work-zone
# zoneadm -z work-zone halt
# zoneadm list -cp
0:global:running:/
-:work-zone:installed:/zones/work-zone

At this point, the zone is not using system resources other than
file system space. Uninstall the zone to remove the zone's file
usage.

# zoneadm -z work-zone uninstall

Are you sure you want to uninstall zone work-zone
(y/[n])? y
# zoneadm list -cp
0:global:running:/
-:work-zone:configured:/export/work-zone

The final step is to delete the configuration of the zone from the
global system with the delete subcommand.

# zonecfg -z work-zone delete

Are you sure you want to delete zone work-zone
(y/[n])? y
# zoneadm list -cp
0:global:running:/

Configuring Zone Resources

Configuring System-wide resources, such as CPUs, physical memory, and file

Zone Resources systems, are shared by all zones. Each zone makes its own unique
demands on these resources. Some zones run lower priority
workloads, some higher priority workloads. You can set limits on
a zone's resource consumption by doing the following:

Allocating file system space

Associating zones with resource pools created on your
system
Configuring zone-wide resource controls
Capping physical memory in each project entry in each
zone

This section describes creating dynamic resource pools and

capping physical memory for projects within zones.

Configuring Zone Resources

Creating Dynamic Resource Pools allow you to place common system
Dynamic elements into pools of resources. In response to changing
Resource Pools resource availability and consumption, the poold daemon in the
global zone can automatically resize these resources.
The poold configuration is held in the libpool configuration.

To achieve this goal, the poold daemon resizes partitionable

resources within constraints specified in the pool's configuration
file. These resources currently are processors, but might soon
include memory, disk storage, and network bandwidth.

The poold daemon processes arbitrary resource consumption and

load statistics. The poold daemon responds to changing
conditions by modifying the system's pool configuration.
Initially, the consumption and load statistics are likely to be
associated with operating system components, but the
architecture supports consumption and load statistics published
by applications, which are part of the Service Management
Facility. The reassignment of resources is based on one or more
documented optimization methods. These methods might be as
simple as minimizing the weighted differences between pool
loads, or as complex as a multi-resource history-based predictor
model.

As more resources become available, for example in response to

a dynamic reconfiguration event, then this new resource is
apportioned to different resource partitions. As load on a given
partition increases, resources are acquired from less heavily
loaded partitions. If none of the global objectives can be satisfied
with the currently available system hardware, poold advertises
this state to any higher-level management frameworks (if any)
present by way of an API. These frameworks have the choice of
modifying the objectives, removing application load, making
additional hardware resources available, or doing nothing.

Configuring Zone Resources

Configuring The poold daemon in the global zone is necessary for the
Resource Pools dynamic resource pool feature to function. The poold daemon
 starts when you enable, and stops when you disable, the pool
facility.

To manipulate resource pools, you must first run the pooladm -

ecommand to enable the pool facility.

Configuring Zone Resources

Using The poolcfg command provides configuration operations on pools

the poolcfgCo and sets. These operations are performed upon an existing
mmand configuration, and take the form of modifications to the specified
configuration file. If you use the -d option, the modifications occur
to the kernel state. Actual activation of the resulting configuration is
achieved by way of the pooladm command. The table lists
the poolcfgoptions and arguments.

poolcfg Options and Arguments

Opti Argument Comment

on

-c info [entity_name] Display configuration (or

specified portion) in human
readable form to standard
output. If no entity is
specified, system information
is displayed.

create [entity_name] Make an entity of the

[property_list] specified type and name.

destroy entity_name Remove the specified entity.

modify entity_name[prope Change the listed properties

rty_list] on the named entity.
 associate pool_name[reso Connect one or more
urce_list] resources to a pool, or replace
one or more existing
connections.

transfer Transfer one or more discrete

to [resource_type]name [co components to a resource.
mponent_list]

transfer [quantity] from[r Transfer a resource quantity

esource_type] from src totgt.
[src] to [tgt]

transfer [quantity] to[res Transfer a resource quantity

ource_type] to tgt fromsrc.
[tgt] from [src]

discover This method is maintained for

backward compatibility, and
has been deprecated in favor
of using pooladm-s.

rename entity_name to Change the name of an entity

new_name on the system to its new
name.

-d N/A Operate directly on the kernel

state. No file name is allowed.

-f command_file Take the commands

from command_file.comman
d_file consists of editing
commands, one per line.

-h N/A Display extended information

about the syntax of editing
commands.
 Note: A library API is provided by libpool. The library can be used by
programs to manipulate pool configuration. Refer
tolibpool(3lib) for more information.

Configuring Zone Resources

poolcfgComman You can use poolcfg to view the current pool configuration
d Examples directly from the kernel state:

You can use poolcfg to read a pool configuration that has been
saved to a file, typically /etc/pooladm.conf.

# poolcfg -c info /etc/pooladm.conf

Note: The /etc/pooladm.conf file does not exist by default. You
can create it using the pooladm -s
/etc/pooladm.conf command. Thepooladm -c command
reads /etc/pooladm.conf by default.

The table lists the properties for this example.

Pool Configuration File Properties

Property Value Comment

system.comment Zones Comment string describing

tester the system.

system.version 1 libpool version required to

manipulate this
configuration.

system.bind- true If specified pool not found,

default bind to pool
withpool.default propert
y set to true. See
 thepool.default property
.

system.poold.pi 44690 System-assigned process ID

d

pool.sys_id 0 System-assigned pool ID.

pool.active true Mark this pool as active, if

true.

pool.default true Mark this pool as the default

pool, if true.
Seesystem.bind-
defaultproperty.

pool.importance 1 Relative importance of this

pool; for possible resource
dispute resolution.

pool.comment The Comment string describing

default the resource pool.
pool

pset.sys_id -1 System-assigned processor

set ID.

pset.default true Marks default processor set.

pset.min 1 Minimum number of CPUs

permitted in this processor
set.

pset.max 65536 Maximum number of CPUs

permitted in this processor
set.
 pset.units populatio Identifies meaning of size-
n related properties; value for
all processor sets is
population.

pset.load 10 The load for this processor

set.

pset.size 2 Current number of CPUs in

this processor set.

pset.comment 2 CPUs! User description of

resource.

cpu.sys_id 0 0 System-assigned CPU ID.

cpu.comment null User description of CPU.

cpu.status on-line CPU status.

To create a processor set consisting of a maximum of two CPUs

in the kernel, type the following command:

# poolcfg -dc `create pset my-1st-pset ( uint

pset.min = 1
; uint pset.max = 2)'

To create a pool in the kernel, type the following command:

# poolcfg -dc `create pool my-1st-pool'

To associate a processor set with a pool in the kernel, type the

following command:

# poolcfg -dc `associate pool my-1st-pool (pset my-

1st-pset)'

Configuring Zone
Resources
Using The pooladm command provides administrative operations
the pooladmCommand on pools and sets. pooladm reads the specified file name
and attempts to activate the pool configuration contained in
it. Before updating the current pool run-time
configuration, pooladm validates the configuration for
correctness. Without options, pooladm prints out the current
running pools configuration.

To enable the pool facility, type the following command:

# pooladm -e

To save the active pool configuration

into /etc/pooladm.conf, type the following command:

# pooladm -s /etc/pooladm.conf
The /etc/pooladm.conf file does not exist by default.

To instantiate the configuration listed

in /etc/pooladm.conf, type the following command:

# pooladm -c

The pooladm -c command reads

the /etc/pooladm.conf file by default, and activates the
configuration that it contains.

To remove any user-defined pools and return the pool

configuration to the default state, type the following
command:

# pooladm -x

Configuring Zone
Resources

Physical The resource capping daemon provides a mechanism for physical

Memory memory resource cap enforcement and administration. A
Control Using resource cap is an upper bound placed on the consumption of a
resource, such as physical memory. Physical memory capping is
the Resource
Capping
Daemon
configured by the zonecfg utility. To cap the memory resource,
you must first establish a project.

Like the resource control, the resource cap is defined by using

attributes of project entries in the project database. However,
while resource controls are synchronously enforced by the kernel,
resource caps are asynchronously enforced at the user level by
the resource capping daemon. With asynchronous enforcement, a
small delay occurs as a result of the sampling interval used by the
daemon.

Configuring a Physical Memory Cap

To define a physical memory resource cap for a project in a non-

global zone, you establish a resident set size (RSS) cap by adding
this attribute to the project database entry rcap.max-rss.

For example, to create a new project database entry in the non-

global zone with the attributes:

Project name = regtool

Project ID = 20
Project group = registry
Comment = Regtool example
RSS cap = 1 Gbyte

Use the projadd and projmod commands:

# projadd -c "Regtool example" -G registry -p 101

regtool
# projmod -s -K rcap.max-rss=1GB regtool

The resulting /etc/project file entry for the project is as

follows:

regtool:101:Regtool example::registry:recap.max-
rss=1024000

After a project with a resource cap is defined, you use

the rcapadm -E command to enable resource capping and
enforce the physical memory limit allocated to a project in a non-
global zone.
 After the project memory has been capped, you can use
the rcapstat command in the noon-global zone to determine if
the resource control is effective.

For example:

$ rcapstat
id project nproc vm rss cap at
avgat pg avgpg
101 regtool 3 4408K 792K 1000K 0K
0K 0K 0K
...

In this rcapstat example, the key fields to observe are:

The vm field is the total virtual memory size of the

project's processes, including all mapped files and
devices.
The rss field is the estimated total memory RSS of the
project's processes.
The cap field indicates the RSS cap defined for the
project.
The at, avgat, pg, and avgpg fields are project page-out
indicators.

The value of rss (792K) is less than the value of cap (1000K)
and the paging indicators show no paging (0K). This indicates the
memory cap is effective.

Configuring Zone Resources

Installing The standard Solaris package management tools, for

Packages in example, pkgaddand pkgrm, are used to administer packages in
Zones the zones environment. The global administrator can use these
tools to manage the software on every zone in the system.

Package parameters listed in the pkginfo file for a package

control how the Solaris package tools can administer the package.
These package parameters determine how package content can be
distributed and made visible among zones, both global and non-
global, in a system.
Currently, three package parameters control how packages are
administered. They are:

o SUNW_PKG_ALLZONES - Defines whether a

package, when installed, must be installed and
must be identical in all zones.
o SUNW_PKG_HOLLOW - Defines whether a
package should be visible in any non-global zone if
that package is required to be installed and to be
identical in all zones (for example, a package that
has SUNW_PKG_ALLZONES=true).
o SUNW_PKG_THISZONE - Defines whether a
package must be installed in the current zone only.

Values of these parameters can only be set to true or false. If one

of these parameters is not defined in a package, its value is
assumed to be false by the package management tools. More
information about the specific effects of these parameters and
how they interact is available in pkginfo(4).

You can list parameters for packages using

the pkgparam command. To display the list of parameters and
their values in a package, usepkgparam -v <package>. For
example:

# pkgparam -v SUNWzoneu
CLASSES='none'
BASEDIR='/'
LANG='C'
PATH='/sbin:/usr/sbin:/usr/bin:/usr/sadm/install/bin'
OAMBASE='/usr/sadm/sysadm'
PKG='SUNWzoneu'
NAME='Solaris Zones (Usr)'
ARCH='sparc'
VERSION='11.10.0,REV=2005.01.21.15.53'
SUNW_PRODNAME='SunOS'
SUNW_PRODVERS='5.10/Generic'
SUNW_PKGTYPE='usr'
MAXINST='1000'
CATEGORY='system'
DESC='Solaris Zones Configuration and Administration'
VENDOR='Sun Microsystems, Inc.'
HOTLINE='Please contact your local service provider'
EMAIL=''
SUNW_PKGVERS='1.0'
SUNW_PKG_ALLZONES='true'
SUNW_PKG_HOLLOW='false'
PSTAMP='gaget20050121155950'
PKGINST='SUNWzoneu'
PKGSAV='/var/sadm/pkg/SUNWzoneu/save'
 INSTDATE='Jan 26 2005 10:21'
#

The -G option to the pkgadd command causes pkgadd to add a

package to the current zone only. When used in the global zone,
the package is added to the global zone only and is not propagated
to any existing or yet-to-be-created non-global zone. When used
in a non-global zone, the package(s) are added to the non-global
zone only.

Configuring Zone Resources

Package If the package is not currently installed in the global zone and not
Operations currently installed in any non-global zone, the package can be
Possible in the installed according to the following guidelines:
Global Zone
Only in the global zone, if
SUNW_PKG_ALLZONES=false
In the global zone and all non-global zones

If the package is currently installed in the global zone only, the

following guidelines apply:

The package can be installed in all non-global zones.

The package can be removed from the global zone.

If a package is currently installed in the global zone and currently

installed in only a subset of the non-global zones, the following
guidelines apply:

SUNW_PKG_ALLZONES must be set to false.

The package can be installed in all non-global zones.
Existing instances in any non-global zone are updated to
the revision being installed.
The package can be removed from the global zone.
The package can be removed from the global zone and
from all non-global zones.

If a package is currently installed in the global zone and currently

installed in all non-global zones, the package can be removed
from the global zone and from all non-global zones.

These rules ensure the following:

 Packages that are installed in the global zone are either
installed in the global zone only, or installed in the global
zone and all non-global zones.
Packages that are installed in the global zone and also
installed in any non-global zone are the same across all
zones.

Configuring Zone Resources

Package The package operations possible in any non-global zone are the
Operations following:
Possible in a
If a package is not currently installed in the non-global
Non-Global
zone, the package can be installed only if
Zone SUNW_PKG_ALLZONES=false.
If a package is currently installed in the non-global zone,
the following guidelines apply:
o The package can be installed over the existing
instance of the package only if
SUNW_PKG_ALLZONES=false.
o The package can be removed from the non-global
zone only if SUNW_PKG_ALLZONES=false.

Note: To upgrade the Solaris Operating System on a system

with non-global zones defined, it is first necessary to remove all
non-global zones, then re-build them after the operating system
upgrade is complete.