Part II Zones

This part covers SolarisTM Zones software partitioning
technology, which provides a means of virtualizing operating system services
to create an isolated environment for running applications. This isolation
prevents processes that are running in one zone from monitoring or affecting
processes running in other zones.

Chapter 15 Introduction to Solaris Zones

The SolarisTM 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 provides
limited information about the ipkg brand for the OpenSolaris
2006.09 release. This design is under development, and the solution for OpenSolaris
might change.

About
Zones in the OpenSolaris 2009.06 Release

Zones on the OpenSolaris release are a work
in progress; they are evolving as development continues. The software management
aspect of zones is changing because OpenSolaris uses IPS instead of SVr4 packaging
and patching. Thus, work in still being done where zones are impacted by software
management, such as installation and migration.

The Image Packaging System (IPS) is a new model for software management
in the OpenSolaris 2009.06 Release, and zones are changing to utilize this
model. The following differences should be noted:

The ipkg brand is the default instead of
the native brand, which is the default on SX systems.

ipkg branded zones are whole-root type
only; inherit-pkg-dir should not be used.

The
sparse root type of zone describes a fundamental interaction between zones
and the package management system, and IPS doesn't support this concept. Sun
is working on providing the positive attributes of sparse root zones in other
ways.

Zones have different software management related functionality
in these areas:

IPS versus SVR4 packaging

Install, detach/attach, "physical to virtual" (P2V) capability

Zones have different global
zone software operations; they employ manual syncing, not patching. Currently,
the zones don't automatically update when you pkg image-update the
system. You must manually update the zones after rebooting to keep them in
sync with the global zone. In a future release, this update should happen
automatically.

Note –

Until pkg_image-update is fully supported,
you can use zoneadmdetach and attach-u as a workaround. Detach the zone before running pkg_image-update, then use attach-u after
running pkg_image-update. See About Migrating a Zone for more information on these commands.

Global zones are integrated with beadm and
use boot environments as described in beadm Zones Support. In a future release, support
for beadm inside zones is planned.

The zone root is a ZFSTM dataset. In
a future release, this feature will enable support for beadm inside
zones for pkg_image-update, just as you can do in the global
zone. To accomplish this, the zone's root dataset must be controlled inside
the zone.

To control the software installed in the ipkg brand
zone, use the -e option to the zoneadminstall command.

# zoneadm -z zonename install -e pkgA -e pkgB ...

For information on zones in the OpenSolaris release, visit the Zones
OpenSolaris Community. This site will be updated to address the latest
issues.

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 the Solaris 10 or later Solaris 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.

There are two types of non-global zone root file
system models: sparse and whole root.

Sparse root zones are native branded zones. The sparse
root zone model optimizes the sharing of objects. Note that some
brands, especially the ipkg brand, do not support the sparse
root model.

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. Every zone is configured with an associated
brand.

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 structure. Most administration procedures are identical for all zones.

BrandZ extends the zones tools in the following ways:

The zonecfg command is used to set a zone's
brand type when the zone is configured.

The zoneadm command is used to report a
zone's brand type as well as administer the zone.

Although you can configure and install branded zones on a Solaris Trusted Extensions system that has labels enabled, you cannot
boot branded zones on this system configuration, unless the
brand being booted is the labeled brand on an OpenSolaris 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 15–1 Zones Server Consolidation Example

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.

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

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

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

Non-Global Zone State Model

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 zoneadmlist-iv.

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.

You can also use zonecfg to rename a zone in the
configured or installed state.

Incomplete

zoneadm-zzonenameuninstall

Installed

zoneadm-zzonenameready (optional)

zoneadm-zzonenameboot

zoneadm-zzonenameuninstall uninstalls the configuration of the specified zone from
the system.

zoneadm-zzonenamemovepath

zoneadm-zzonenamedetach

zonecfg-zzonename can
be used to add or remove an attr, bootargs, capped-memory, dataset, capped-cpu, 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-zzonenameboot

zoneadmhalt and system reboot
return a zone in the ready state to the installed state.

zoneadmhalt and system reboot
return a zone in the running state to the installed state.

zonecfg-zzonename can
be used to add or remove an attr, bootargs, capped-memory, dataset, capped-cpu, 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.

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

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.

As global administrator, perform the initial internal configuration
of the zone.

Place a sysidcfg file in the zone's /etc directory
or log in to each non-global zone using the zlogin command
with the -C option and enter the requested information, including
assigning the zone root password.

About Resources in Zones

A zone that includes resource management features is called a container.
Resources that can be controlled in a container include the following:

Resource pools or assigned CPUs, which are used for partitioning
machine resources.

Resource controls, which provide a mechanism for the constraint
of system resources.

Scheduling class, which enables you to control the allocation
of available CPU resources among zones, based on their importance. This importance
is expressed by the number of shares of CPU resources that you assign to each
zone.

Pre-Installation Configuration Process

Before you can install a non-global zone and use it
on your system, the zone must be configured.

The zonecfg command is used to create the configuration
and to determine whether the specified resources and properties are valid
on a hypothetical system. The check performed by zonecfg for
a given configuration verifies the following:

Ensures that a zone path is specified

Ensures that all of the required properties for each resource
are specified

For more information about the zonecfg command, see
the zonecfg(1M) man
page.

Zone Components

This section covers the required and optional zone components that can
be configured. Additional information is provided in Zone Configuration Data.

Zone Name and Path

You must choose a name and a path for your zone.

Zone Autoboot

The autoboot property setting determines whether
the zone is automatically booted when the global zone is booted. The zones
service, svc:/system/zones:default must also be enabled.

If you do not have resource pools configured, you can still specify
that a subset of the system's processors be dedicated to a non-global zone
while it is running by using the dedicated-cpu resource.
The system will dynamically create a temporary pool for use while the zone
is running. With specification through zonecfg, pool settings
propagate during migrations.

Note –

A zone configuration using a persistent pool set through the pool property is incompatible with a temporary pool configured through
the dedicated-cpu resource. You can set only one of these
two properties.

dedicated-cpu Resource

The dedicated-cpu resource specifies that a
subset of the system's processors should be dedicated to a non-global zone
while it is running. When the zone boots, the system will dynamically create
a temporary pool for use while the zone is running.

With specification in zonecfg, pool settings propagate
during migrations.

The dedicated-cpu resource sets limits for ncpus, and optionally, importance.

ncpus

Specify the number of CPUs or specify a range, such as 2–4
CPUs. If you specify a range because you want dynamic resource pool behavior,
also do the following:

If you are using a CPU range to achieve dynamic behavior,
also set the importance property, The importance property,
which is optional, defines the relative importance of
the pool. This property is only needed when you specify a range for ncpus and are using dynamic resource pools managed by poold.
If poold is not running, then importance is
ignored. If poold is running and importance is
not set, importance defaults to 1. For
more information, see pool.importance Property Constraint.

Note –

The capped-cpu resource and the dedicated-cpu resource are incompatible. The cpu-shares rctl
and the dedicated-cpu resource are incompatible.

capped-cpu Resource

The capped-cpu resource
provides an absolute fine-grained limit on the amount of CPU resources that
can be consumed by a project or a zone. When used in conjunction with processor
sets, CPU caps limit CPU usage within a set. The capped-cpu resource
has a single ncpus property that is a positive decimal
with two digits to the right of the decimal. This property corresponds to
units of CPUs. The resource does not accept a range. The resource does accept
a decimal number. When specifying ncpus, a value of 1 means 100 percent of a CPU. A value of 1.25 means
125 percent, because 100 percent corresponds to one full CPU on the system.

Note –

The capped-cpu resource and the dedicated-cpu resource are incompatible.

Scheduling Class

You
can use the fair share scheduler (FSS) to control the
allocation of available CPU resources among zones, based on their importance.
This importance is expressed by the number of shares of
CPU resources that you assign to each zone. Even if you are not using FSS
to manage CPU resource allocation between zones, you can set the zone's scheduling-class
to use FSS so that you can set shares on projects within the zone.

When you explicitly set the cpu-shares property,
the fair share scheduler (FSS) will be used as the scheduling class for that
zone. However, the preferred way to use FSS in this case is to set FSS to
be the system default scheduling class with the dispadmin command.
That way, all zones will benefit from getting a fair share of the system CPU
resources. If cpu-shares is not set for a zone, the zone
will use the system default scheduling class. The following actions set the
scheduling class for a zone:

You can use the scheduling-class property
in zonecfg to set the scheduling class for the zone.

If the cpu-shares rctl is set and FSS has
not been set as the scheduling class for the zone through another action, zoneadmd sets the scheduling class to FSS when the zone boots.

If the scheduling class is not set through any other action,
the zone inherits the system default scheduling class.

Note that 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.

Physical Memory Control and the capped-memory Resource

The capped-memory resource sets limits for physical, swap, and locked memory.
Each limit is optional, but at least one must be set.

Determine
values for this resource if you plan to cap memory for the zone by using rcapd from the global zone. The physical property
of the capped-memory resource is used by rcapd as
the max-rss value for the zone.

The swap property of the capped-memory resource is
the preferred way to set the zone.max-swap resource control.

The locked property of the capped-memory resource
is the preferred way to set the zone.max-locked-memory resource
control.

Note –

Applications
generally do not lock significant amounts of memory, but you might decide
to set locked memory if the zone's applications are known to lock memory.
If zone trust is a concern, you can also consider setting the locked memory
cap to 10 percent of the system's physical memory, or 10 percent of the zone's
physical memory cap.

Shared-IP Non-Global Zones

The
shared-IP zone is the default type. The zone must have one or more dedicated
IP addresses. A shared-IP zone shares the IP layer configuration and state
with the global zone. The zone should use the shared-IP instance if both of
the following are true:

The zone is to be connected to the same data-link, that is,
be on the same IP subnet or subnets as the global zone

You do not want the other capabilities that the exclusive-IP
zone provides.

Shared-IP zones are assigned one or more IP addresses using the zonecfg command. The data-link names must also be configured in the global
zone.

In the zonecfgnet resource, the address and the physical properties must be set.
The defrouter property is optional.

These addresses are associated with logical network interfaces. The ifconfig command can be used from the global zone to add or remove
logical interfaces in a running zone. For more information, see Shared-IP Network Interfaces.

Exclusive-IP Non-Global Zones

Full
IP-level functionality is available in an exclusive-IP zone.

An exclusive-IP zone has its own IP-related state.

This includes the ability to use the following features in an exclusive-IP
zone:

An exclusive-IP zone is assigned its own set of data-links using
the zonecfg command. The zone is given a data-link name
such as xge0, e1000g1, or bge32001, using the physical property of the net resource.
The address and the defrouter properties
of the net resource are not set.

Note that the assigned data-link enables the snoop command
to be used.

The dladm command can be used with the show-linkprop subcommand to show the assignment of data-links to running exclusive-IP
zones. The dladm command can be used with the set-linkprop subcommand to assign additional data-links to running zones. See Administering Data-Links in Exclusive-IP Non-Global Zones for
usage examples.

Inside a running exclusive-IP zone, the ifconfig command
can be used to configure IP, which includes the ability to add or remove logical
interfaces. The IP configuration in a zone can be set up in the same way as
for the global zone, by using the sysidtools described
in sysidcfg(4).

Note –

The IP configuration of an exclusive-IP zone can only be viewed
from the global zone by using the zlogin command. An example
follows.

In a shared-IP zone, applications in the zone, including the superuser,
cannot send packets with source IP addresses other than the ones assigned
to the zone through the zonecfg utility. This type of zone
does not have access to send and receive arbitrary data-link (layer 2) packets.

For an exclusive-IP zone, zonecfg instead grants
the entire specified data-link to the zone. As a result, the superuser in
an exclusive-IP zone can send spoofed packets on those data-links, just as
can be done in the global zone.

Using Shared-IP and Exclusive-IP Non-Global Zones
at the Same Time

The shared-IP zones always share the IP layer with the global zone,
and the exclusive-IP zones always have their own instance of the IP layer.
Both shared-IP zones and exclusive-IP zones can be used on the same machine.

File Systems Mounted in Zones

Generally, the file systems mounted in a zone include the following:

The set of file systems mounted when the virtual platform
is initialized

The set of file systems mounted from within the application
environment itself

This can include, for example, the following file systems:

File systems specified in a zone's /etc/vfstab file

AutoFS and AutoFS-triggered
mounts

Mounts explicitly performed by a zone administrator

Certain restrictions are placed on mounts performed from within the
application environment. These restrictions prevent the zone administrator
from denying service to the rest of the system, or otherwise negatively impacting
other zones.

There are security restrictions associated with mounting certain file
systems from within a zone. Other file systems exhibit special behavior when
mounted in a zone. See File Systems and Non-Global Zones for more information.

Host
ID in Zones

You can set a hostid property for the non-global
zone that is different from the hostid of the global zone.
This would be done, for example, in the case of a machine migrated into a
zone on another system. Applications now inside the zone might depend on the
original hostid. See Resource and Property Types for more information.

Configured Devices in Zones

The zonecfg command uses a rule-matching system to
specify which devices should appear in a particular zone. Devices matching
one of the rules are included in the zone's /dev file system.
For more information, see How to Configure the Zone.

Setting Zone-Wide Resource Controls

The
global administrator can set privileged zone-wide resource controls for a
zone. Zone-wide resource controls limit the total resource usage of all process
entities within a zone.

These limits are specified for both the global and non-global zones
by using the zonecfg command. See How to Configure the Zone.

The preferred, simpler method for setting a zone-wide resource control
is to use the property name instead of the rctl resource.

The zone.cpu-cap resource control sets an absolute
limit on the amount of CPU resources that can be consumed by a zone. A value
of 100 means 100 percent of one CPU as the project.cpu-cap setting. A value of 125 is 125 percent, because
100 percent corresponds to one full CPU on the system when using CPU caps.

Note –

When setting the capped-cpu resource, you can
use a decimal number for the unit. The value correlates to the zone.capped-cpu resource control, but the setting is scaled down by 100. A setting
of 1 is equivalent to a setting of 100 for
the resource control.

The zone.cpu-shares resource control sets a
limit on the number of fair share scheduler (FSS) CPU shares for a zone. CPU
shares are first allocated to the zone, and then further subdivided among
projects within the zone as specified in the project.cpu-shares entries.
For more information, see Using the Fair Share Scheduler on a Solaris System With Zones Installed. The global
property name for this control is cpu-shares.

The zone.max-locked-memory resource
control limits the amount of locked physical memory available to a zone The
allocation of the locked memory resource across projects within the zone can
be controlled by using the project.max-locked-memory resource
control. See Table 6–1 for
more information.

The zone.max-lwps resource control enhances
resource isolation by preventing too many LWPs in one zone from affecting
other zones. The allocation of the LWP resource across projects within the
zone can be controlled by using the project.max-lwps resource
control. See Table 6–1 for
more information. The global property name for this control is max-lwps.

The zone.max-msg-ids, zone.max-sem-ids, zone.max-shm-ids, and zone.max-shm-memory resource controls are used to limit System V resources used by
all processes within a zone. The allocation of System V resources across projects
within the zone can be controlled by using the project versions of these resource
controls. The global property names for these controls are max-msg-ids, max-sem-ids, max-shm-ids, and max-shm-memory.

The zone.max-swap resource control limits swap
consumed by user process address space mappings and tmpfs mounts
within a zone. The output of prstat-Z displays
a SWAP column. The swap reported is the total swap consumed by the zone's
processes and tmpfs mounts. This value assists in monitoring
the swap reserved by each zone, which can be used to choose an appropriate zone.max-swap setting.

Table 16–1 Zone-Wide Resource Controls

Control Name

Global Property Name

Description

Default Unit

Value Used For

zone.cpu-cap

Absolute limit on the amount of CPU resources for this zone

Quantity (number of CPUs), expressed as a percentage

Note –

When setting as the capped-cpu resource, you
can use a decimal number for the unit.

zone.cpu-shares

cpu-shares

Number of fair share scheduler (FSS) CPU shares for this zone

Quantity (shares)

zone.max-locked-memory

Total amount of physical locked memory available to a zone.

If priv_proc_lock_memory is assigned to a zone, consider
setting this resource control as well, to prevent that zone from locking all
memory.

Size (bytes)

locked property of capped-memory

zone.max-lwps

max-lwps

Maximum number of LWPs simultaneously available to this zone

Quantity (LWPs)

zone.max-msg-ids

max-msg-ids

Maximum number of message queue IDs allowed for this zone

Quantity (message queue IDs)

zone.max-sem-ids

max-sem-ids

Maximum number of semaphore IDs allowed for this zone

Quantity (semaphore IDs)

zone.max-shm-ids

max-shm-ids

Maximum number of shared memory IDs allowed for this zone

Quantity (shared memory IDs)

zone.max-shm-memory

max-shm-memory

Total amount of System V shared memory allowed for this zone

Size (bytes)

zone.max-swap

Total amount of swap that can be consumed by user process address space
mappings and tmpfs mounts for this zone.

Configurable Privileges

When a zone is booted, a default set of safe privileges
is included in the configuration. These privileges are considered safe because
they prevent a privileged process in the zone from affecting processes in
other non-global zones on the system or in the global zone. You can use the zonecfg command to do the following:

Add to the default set of privileges, understanding that such
changes might allow processes in one zone to affect processes in other zones
by being able to control a global resource.

Remove from the default set of privileges, understanding that
such changes might prevent some processes from operating correctly if they
require those privileges to run.

Note –

There are a few privileges that cannot be removed from the zone's
default privilege set, and there are also a few privileges that cannot be
added to the set at this time.

Including a Comment for a Zone

Using the zonecfg Command

The zonecfg command,
which is described in the zonecfg(1M) man page, is used to configure a
non-global zone.

The zonecfg command can also be used to persistently
specify the resource management settings for the global zone. For example,
you can use the command to configure the global zone to use a dedicated CPU
by using the dedicated-cpu resource.

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

Create or delete (destroy) a zone configuration

Add resources to a particular configuration

Set properties for resources added to a configuration

Remove resources from a particular configuration

Query or verify a configuration

Commit to a configuration

Revert to a previous configuration

Rename a zone

Exit from a zonecfg session

The zonecfg prompt is of the following form:

zonecfg:zonename>

When you are configuring a specific resource type, such as a file system,
that resource type is also included in the prompt:

zonecfg Modes

The concept of a scope is used
for the user interface. The scope can be either global or resource specific. The default scope is global.

In the global scope,
the add subcommand and the select subcommand
are used to select a specific resource. The scope then changes to that resource
type.

For the add subcommand, the end or cancel subcommands are used to complete the resource specification.

For the select subcommand, the end or cancel subcommands are used to complete the resource modification.

The scope then reverts back to global.

Certain subcommands, such as add, remove,
and set, have different semantics in each scope.

zonecfg Interactive Mode

In interactive mode, the following subcommands are
supported. For detailed information about semantics and options used with
the subcommands, see the zonecfg(1M) man page for options. For any subcommand
that could result in destructive actions or loss of work, the system requests
user confirmation before proceeding. You can use the -F (force)
option to bypass this confirmation.

help

Print general help, or display help about a given resource.

zonecfg:my-zone:inherit-pkg-dir> help

create

Begin configuring an in-memory configuration for the specified
new zone for one of these purposes:

To apply the Sun default settings to a new configuration.
This method is the default.

With the -ttemplate option,
to create a configuration that is identical to the specified template. The
zone name is changed from the template name to the new zone name.

With the -F option, to overwrite an existing
configuration.

With the -b option, to create a blank configuration
in which nothing is set.

export

Print the configuration to standard output, or to the output
file specified, in a form that can be used in a command file.

add

In the global scope, add the specified resource type to the
configuration.

In the resource scope, add a property of the given name with the given
value.

Set a given property name to the given property value. Note
that some properties, such as zonepath, are global, while
others are resource specific. Thus, this command is applicable in both the
global and resource scopes.

select

Applicable only in the global scope. Select the resource of
the given type that matches the given property name-property value pair criteria
for modification. The scope is changed to that resource type. You must specify
a sufficient number of property name-value pairs for the resource to be uniquely
identified.

clear

Clear the value for optional settings. Required settings cannot
be cleared. However, some required settings can be changed by assigning a
new value.

remove

In the global scope, remove the specified resource type. You
must specify a sufficient number of property name-value pairs for the resource
type to be uniquely identified. If no property name-value pairs are specified,
all instances will be removed. If more than one exists, a confirmation is
required unless the -F option is used.

In the resource scope, remove the specified property name-property value
from the current resource.

end

Applicable only in the resource scope. End the resource specification.

The zonecfg command then verifies that the current
resource is fully specified.

If the resource is fully specified, it is added to the in-memory
configuration and the scope will revert back to global.

If the specification is incomplete, the system displays an
error message that describes what needs to be done.

cancel

Applicable only in the resource scope. End the resource specification
and reset the scope to global. Any partially specified resources are not retained.

delete

Destroy the specified configuration. Delete the configuration
both from memory and from stable storage. You must use the -F (force)
option with delete.

Caution –

This action is instantaneous. No commit is required, and a
deleted zone cannot be reverted.

info

Display information about the current configuration or the
global resource properties zonepath, autoboot,
and pool. If a resource type is specified, display information
only about resources of that type. In the resource scope, this subcommand
applies only to the resource being added or modified.

verify

Verify current configuration for correctness. Ensure that
all resources have all of their required properties specified.

commit

Commit 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 zoneadm. 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.

revert

Revert configuration back to the last committed state.

exit

Exit the zonecfg session. You can use
the -F (force) option with exit.

A commit is automatically attempted if needed. Note
that an EOF character can also be used to exit the session.

zonecfg Command-File
Mode

In command-file mode, input is taken from a file. The export subcommand
described in zonecfg Interactive Mode is
used to produce this file. The configuration can be printed to standard output,
or the -f option can be used to specify an output file.

Zone Configuration Data

Zone configuration data consists of two kinds of entities:
resources and properties. Each resource has a type, and each resource can
also have a set of one or more properties. The properties have names and values.
The set of properties is dependent on the resource type.

Resource and Property Types

The resource and property types are
described as follows:

zonename

The name of the zone. The following rules apply to zone names:

Each zone must have a unique name.

A zone name is case-sensitive.

A zone name must begin with an alphanumeric character.

The name can contain alphanumeric characters, underbars (_),
hyphens (-), and periods (.).

The name cannot be longer than 64 characters.

The name global and all names beginning
with SUNW are reserved and cannot be used.

zonepath

The zonepath property is the path to the
zone root. Each zone has a path to its root directory that is relative to
the global zone's root directory. At installation time, the global zone directory
is required to have restricted visibility. It must be owned by root with
the mode 700.

The non-global zone's root path is one level lower. The zone's root
directory has the same ownership and permissions as the root directory (/) in the global zone. The zone directory must be owned by root with the mode 755. These directories are created
automatically with the correct permissions, and do not need to be verified
by the zone administrator. This hierarchy ensures that unprivileged users
in the global zone are prevented from traversing a non-global zone's file
system.

You can move a zone to another location on the same system by
specifying a new, full zonepath with the move subcommand
of zoneadm. See Moving a Non-Global Zone for instructions.

autoboot

If this property is set to true, the zone is automatically
booted when the global zone is booted. Note that if the zones service, svc:/system/zones:default is disabled, the zone will not autoboot, regardless of the setting
of this property. You can enable the zones service with the svcadm command
described in the svcadm(1M) man
page:

global# svcadm enable zones

bootargs

This property is used to set a boot argument for the zone. The
boot argument is applied unless overridden by the reboot, zoneadm boot, or zoneadm reboot commands. See Zone Boot Arguments.

pool

This property is used to associate the zone with a resource pool
on the system. Multiple zones can share the resources of one pool. Also see dedicated-cpu Resource.

Privileges are added by specifying the privilege name, with or without
the leading priv_. Privileges are excluded by preceding
the name with a dash (-) or an exclamation mark (!).
The privilege values are separated by commas and placed within quotation marks
(“).

As described in priv_str_to_set(3C), the special privilege sets
of none, all, and basic expand
to their normal definitions. Because zone configuration takes place from the
global zone, the special privilege set zone cannot be used.
Because a common use is to alter the default privilege set by adding or removing
certain privileges, the special set default maps to the
default, set of privileges. When default appears at the
beginning of the limitpriv property, it expands to the
default set.

The following entry adds the ability to use DTrace programs that only
require the dtrace_proc and dtrace_user privileges
in the zone:

If the zone's privilege set contains a disallowed privilege, is missing
a required privilege, or includes an unknown privilege, an attempt to verify,
ready, or boot the zone will fail with an error message.

scheduling-class

This property sets the scheduling class
for the zone. See Scheduling Class for additional
information and tips.

This resource dedicates a subset of the system's processors to
the zone while it is running. The dedicated-cpu resource
provides limits for ncpus and, optionally, importance. For more information, see dedicated-cpu Resource.

capped-cpu

This resource sets a limit on the amount of CPU resources that
can be consumed by the zone while it is running. The capped-cpu resource
provides a limit for ncpus. For more information, see capped-cpu Resource.

capped-memory

This resource groups the properties used when capping memory for
the zone. The capped-memory resource provides limits for physical, swap, and locked memory.
At least one of these properties must be specified.

dataset

Adding a ZFSTM dataset resource enables the
delegation of storage administration to a non-global zone. The zone administrator
can create and destroy file systems within that dataset, and modify properties
of the dataset. The zone administrator cannot affect datasets that have not
been added to the zone or exceed any top level quotas set on the dataset assigned
to the zone.

ZFS datasets can be added to a zone in the following ways.

As an lofs mounted file system, when the goal is solely to
share space with the global zone

Each zone can have various file systems that are mounted when
the zone transitions from the installed state to the ready state. The file
system resource specifies the path to the file system mount point. For more
information about the use of file systems in zones, see File Systems and Non-Global Zones.

inherit-pkg-dir (native brand only)

OpenSolaris native brand: This
resource should not be configured in a whole root zone.

In a native branded sparse root zone, the inherit-pkg-dir resource
is used to represent directories that contain packaged software that a non-global
zone shares with the global zone.

The contents of software packages transferred into the inherit-pkg-dir directory are inherited in read-only mode by the non-global zone.
The zone's packaging database is updated to reflect the packages. These resources
cannot be modified or removed after the zone has been installed using zoneadm.

Note –

Four default inherit-pkg-dir resources are
included in the configuration. These directory resources indicate which directories
should have their associated packages inherited from the global zone. The
resources are implemented through a read-only loopback file system mount.

/lib

/platform

/sbin

/usr

net

The network interface resource is the interface name. Each
zone can have network interfaces that should be set up when the zone transitions
from the installed state to the ready state.

device

The device resource is the device matching specifier. Each
zone can have devices that should be configured when the zone transitions
from the installed state to the ready state.

rctl

The rctl resource is used for zone-wide
resource controls. The controls are enabled when the zone transitions from
the installed state to the ready state.

To configure zone-wide controls using the setglobal_property_name subcommand of zonefig instead
of the rctl resource, see How to Configure the Zone.

hostid

A hostid that is different from the hostid of the global zone can be set.

attr

This generic attribute can be used for user comments or by
other subsystems. The name property of an attr must
begin with an alphanumeric character. The name property
can contain alphanumeric characters, hyphens (-), and periods
(.). Attribute names beginning with zone. are
reserved for use by the system.

Resource Type Properties

Resources also have properties to configure. The following properties
are associated with the resource types shown.

dedicated-cpu

ncpus, importance

Specify the number of CPUs and, optionally, the relative importance
of the pool. The following example specifies a CPU range for use by the zone my-zone. importance is also set.

The fs resource parameters supply the values that
determine how and where to mount file systems. The fs parameters
are defined as follows:

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 fsck before
mounting the file system

type

Specifies the file system type

options

Specifies mount options similar to those found with the mount command

The lines in the following example specify that /dev/dsk/c0t0d0s2 in
the global zone is to be mounted as /mnt in a zone being
configured. The raw property specifies an optional device
on which the fsck command is to be run before an attempt
is made to mount the file system. The file system type to use is UFS. The
options nodevices and logging are added.

For a shared-IP zone, both the IP address and the device are specified.
Optionally, the default router can be set. For an exclusive-IP zone, only
the physical interface is specified.

In the following example for a shared-IP zone, the IP address 192.168.0.1 is added to the zone. An hme0 card is used for
the physical interface. To determine which physical interface to use, type ifconfig-a on your system. Each line of the output,
other than loopback driver lines, begins with the name of a card installed
on your system. Lines that contain LOOPBACK in the descriptions
do not apply to cards. The default route is set to 10.0.0.1 for
the zone.

In the following example for an exclusive-IP zone, a bge32001 link
is used for the physical interface, which is a VLAN on bge1.
To determine which data-links are available, use the command dladmshow-link. Note that ip-type=exclusive must also
be specified.

The OpenSolarisTM OS supports all Ethernet-type interfaces, and their data-links
can be administered with the dladm command. Prior
to OpenSolaris build snv_83, the data-link must be GLDv3 to be used with exclusive-IP
zones. Network interface cards (NICs)
that support GLDv3 include bge, e1000g, xge, nge, and rge.
The ce legacy
device can also support an exclusive-IP zone.

Note that the preferred, simpler method for setting a zone-wide resource
control is to use the property name instead of the rctl resource,
as shown in How to Configure the Zone.
If zone-wide resource control entries in a zone are configured using addrctl, the format is different than resource
control entries in the project database. In a zone configuration,
the rctl resource type consists of three name/value pairs.
The names are priv, limit, and action. Each of the names takes a simple value.

You can use the export subcommand to print a zone
configuration to standard output. The configuration is saved in a form that
can be used in a command file.

Tecla Command-Line Editing Library

The Tecla command-line editing library is included for use with the zonecfg command. The library provides a mechanism for command-line
history and editing support.

The Tecla command-line editing library is documented in the following
man pages:

enhance(1)

libtecla(3LIB)

ef_expand_file(3TECLA)

gl_get_line(3TECLA)

gl_io_mode(3TECLA)

pca_lookup_file(3TECLA)

tecla(5)

Chapter 17 Planning and Configuring Non-Global Zones
(Tasks)

This chapter describes what you need to do before you can configure
a zone on your system. This chapter also describes how to configure a zone,
modify a zone configuration, and delete a zone configuration from your system.

Determine whether the zone will be a shared-IP zone or an exclusive-IP
zone.

For a shared-IP zone, which is the default, obtain or configure IP addresses
for the zone. Depending on your configuration, you must obtain at least one
IP address for each non-global zone that you want to have network access.

For an exclusive-IP zone, determine the data-link that will be assigned
to the zone. The zone requires exclusive access to one or more network interfaces.
The interface could be a separate LAN such as bge1, or
a separate VLAN such as bge2000. Prior to OpenSolarisTM build snv_83, the data-link must be GLDv3. The ce legacy
device is an exception. This device can support an exclusive-IP zone.

Evaluating the Current System Setup

Zones can be used on any machine that runs the Solaris 10 or later release.
The following primary machine considerations are associated with the use of
zones.

The performance requirements of the applications running within
each zone.

The availability of disk space to hold the files that are
unique within each zone.

Disk Space Requirements

There are no limits on how much disk space can be consumed by
a zone. The global administrator is responsible for space restriction. The
global administrator must ensure that local storage is sufficient to hold
a non-global zone's root file system. 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.

Sparse Root Zones

Non-global zones that have inherit-pkg-dir resources
are called sparse root zones.
On OpenSolaris 2006.09, sparse root zones are native branded zones. See the native(5) man
page for more information on these types of branded zones.

The sparse root zone model optimizes the sharing of objects in the following
ways:

Only a subset of the packages installed in the global zone
are installed directly into the non-global zone.

Read-only loopback file systems, identified as inherit-pkg-dir resources, are used to gain access to other files.

In this model, all packages appear to be installed in the non-global
zone. Packages that do not deliver content into read-only loopback mount
file systems are fully installed. There is no need to install content delivered
into read-only loopback mounted file systems since that content is inherited
(and visible) from the global zone.

As a general guideline, a zone requires about 100 megabytes
of free disk space per zone when the global zone has been installed with all
of the standard Solaris packages.

By default, any additional packages installed in the global
zone also populate the non-global zones. The amount of disk space required
might be increased accordingly, depending on whether the additional packages
deliver files that reside in the inherit-pkg-dir resource
space.

An additional 40 megabytes of RAM per zone are suggested, but not required
on a machine with sufficient swap space.

Whole Root Zones

The whole root zone model provides the maximum configurability. All
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 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 –

If you create a sparse root zone that contains the following inherit-pkg-dir directories, you must remove these directories from
the non-global zone's configuration before the zone is installed to
have a whole root zone :

Restricting Zone Size

The following options can be used to restrict zone size:

You can place the zone on a lofi-mounted
partition. This action will limit the amount of space consumed by the zone
to that of the file used by lofi. For more information,
see the lofiadm(1M) and lofi(7D) man pages.

You can use the standard partitions of a disk for zone roots,
and thus limit per-zone disk consumption.

Determine the Zone Host Name and the Network Requirements

You must determine the host name for the zone. Then, for a shared IP zone, you
must assign an IPv4 address or manually configure and assign an IPv6 address
for the zone if you want it to have network connectivity. Inside an exclusive-IP zone, you configure
addresses as you do for the global zone.

Zone Host Name

The host name
you select for the zone must be defined either in the hosts database
or in the /etc/inet/hosts database, as specified by the /etc/nsswitch.conf file in the global zone. The network databases
are files that provide network configuration information. The nsswitch.conf file specifies which naming service to use.

If you use local files for the naming service, the hosts database
is maintained in the /etc/inet/hosts file. The host names
for zone network interfaces are resolved from the local hosts database
in /etc/inet/hosts. Alternatively, the IP address itself
can be specified directly when configuring a zone so that no host name resolution
is required.

Shared-IP Zone Network Address

Each shared-IP zone that requires network connectivity has one
or more unique IP addresses. Both IPv4 and IPv6 addresses are supported.

IPv4 Zone Network Address

If you are using IPv4, obtain an address and assign the address to the
zone.

A prefix length can also be specified with the IP address. The format
of this prefix is address/prefix-length,
for example, 192.168.1.1/24. Thus, the address to use is 192.168.1.1 and the netmask to use is 255.255.255.0,
or the mask where the first 24 bits are 1-bits.

IPv6 Zone Network Address

If you are using IPv6, you must manually configure the address. Typically,
at least the following two types of addresses must be configured:

Link-local address

A link-local address is of the form fe80::64-bit interface ID/10. The /10 indicates
a prefix length of 10 bits.

Address formed from a global prefix configured on the
subnet

A global unicast address is based off a 64–bit prefix
that the administrator configures for each subnet, and a 64-bit interface
ID. The prefix can also be obtained by running the ifconfig command
with the -a6 option on any system on the same subnet that
has been configured to use IPv6.

The 64–bit interface ID is typically derived from a system's MAC
address. For zones use, an alternate address that is unique can be derived
from the global zone's IPv4 address as follows:

For example, if the global zone's IPv4 address is 192.168.200.10, a
suitable link-local address for a non-global zone using a zone-unique number
of 1 is fe80::c0a8:c80a:1/10. If the
global prefix in use on that subnet is 2001:0db8:aabb:ccdd/64,
a unique global unicast address for the same non-global zone is 2001:0db8:aabb:ccdd::c0a8:c80a:1/64. Note that you must specify a prefix length when configuring an
IPv6 address.

For more information about link-local and global unicast addresses,
see the inet6(7P) ma
page.

Exclusive-IP Zone Network Address

Inside an exclusive-IP zone, configure addresses as you do for the global
zone. Note that DHCP and IPv6 stateless address autoconfiguration can be used
to configure addresses.

File System Configuration

You can specify a number of mounts to be performed when the virtual
platform is set up. File systems that are loopback-mounted into a zone by
using the loopback virtual file system (LOFS) file system should be mounted
with the nodevices option. For information on the nodevices option, see File Systems and Non-Global Zones.

LOFS lets you create a new virtual file system so that you can access
files by using an alternative path name. In a non-global zone, a loopback
mount makes the file system hierarchy look as though it is duplicated under
the zone's root. In the zone, all files will be accessible with a path name
that starts from the zone's root. LOFS mounting preserves the file system
name space.

How to Configure the Zone

Note that the only required elements to create a native non-global zone
are the zonename and zonepath properties.
Other resources and properties are optional. Some optional resources also
require choices between alternatives, such as the decision to use either the dedicated-cpu resource or the capped-cpu resource.
See Zone Configuration Data for
information on available zonecfg properties and resources.

You must be the global administrator in the global zone to perform this
procedure.

If this is the first time you have configured this zone, you will see
the following system message:

my-zone: No such zone configured
Use 'create' to begin configuring a new zone.

Create the new zone configuration.

This procedure uses the Sun default settings.

zonecfg:my-zone> create

Set the zone path, /export/home/my-zone in this procedure.

zonecfg:my-zone> set zonepath=/export/home/my-zone

Set the autoboot value.

If
set to true, the zone is automatically booted when the
global zone is booted. Note that for the zones to autoboot, the zones service svc:/system/zones:default must also be enabled. The default value
is false.

zonecfg:my-zone> set autoboot=true

Set persistent boot arguments for a zone.

zonecfg:my-zone> set bootargs="-m verbose"

Dedicate one CPU to this zone.

zonecfg:my-zone> add dedicated-cpu

Set the number of CPUs.

zonecfg:my-zone:dedicated-cpu> set ncpus=1-2

(Optional) Set the importance.

zonecfg:my-zone:dedicated-cpu> set importance=10

The default is 1.

End the specification.

zonecfg:my-zone:dedicated-cpu> end

Revise the default set of privileges.

zonecfg:my-zone> set limitpriv="default,sys_time"

This line adds the ability to set the system clock to the default set
of privileges.

Set the scheduling class to FSS.

zonecfg:my-zone> set scheduling-class=FSS

Add a memory cap.

zonecfg:my-zone> add capped-memory

Set the memory cap.

zonecfg:my-zone:capped-memory> set physical=50m

Set the swap memory cap.

zonecfg:my-zone:capped-memory> set swap=100m

Set the locked memory cap.

zonecfg:my-zone:capped-memory> set locked=30m

End the memory cap specification.

zonecfg:my-zone:capped-memory> end

Add a file system.

zonecfg:my-zone> add fs

Set the mount point for the file system, /usr/local in this procedure.

zonecfg:my-zone:fs> set dir=/usr/local

Specify that /opt/local in
the global zone is to be mounted as /usr/local in the zone
being configured.

zonecfg:my-zone:fs> set special=/opt/local

In the non-global zone, the /usr/local file system
will be readable and writable.

Specify the file system type, lofs in this procedure.

zonecfg:my-zone:fs> set type=lofs

The type indicates how the kernel interacts with the file system.

End the file system specification.

zonecfg:my-zone:fs> end

This step can be performed more than once to add more than one file
system.

(Optional)
Set the hostid.

zonecfg:my-zone> set hostid=80f0c086

Add a ZFS dataset named sales in the
storage pool tank

zonecfg:my-zone> add dataset

Specify the path to the ZFS dataset sales.

zonecfg:my-zone> set name=tank/sales

End the dataset specification.

zonecfg:my-zone> end

(Sparse Root Zone Only) Add a shared
file system that is loopback-mounted from the global zone.

Do not perform this step to create a whole root zone, which does not
have any shared file systems. See the discussion for whole root zones in Disk Space Requirements.

zonecfg:my-zone> add inherit-pkg-dir

Specify that /opt/sfw in
the global zone is to be mounted in read-only mode in the zone being configured.

zonecfg:my-zone:inherit-pkg-dir> set dir=/opt/sfw

Note –

The zone's packaging database is updated to reflect the packages.
These resources cannot be modified or removed after the zone has been installed
using zoneadm.

End the inherit-pkg-dir specification.

zonecfg:my-zone:inherit-pkg-dir> end

This step can be performed more than once to add more than one shared
file system.

Note –

If you want to create a whole root zone but default shared file
systems resources have been added by using inherit-pkg-dir,
you must remove these default inherit-pkg-dir resources
using zonecfgbefore you install the
zone:

zonecfg:my-zone>remove inherit-pkg-dir
dir=/lib

zonecfg:my-zone>remove inherit-pkg-dir
dir=/platform

zonecfg:my-zone>remove inherit-pkg-dir
dir=/sbin

zonecfg:my-zone>remove inherit-pkg-dir
dir=/usr

(Optional) If you are creating an exclusive-IP zone, set the ip-type.

zonecfg:my-zone> set ip-type=exclusive

Note –

Only the physical device type will be specified in the add
net step.

Add a network interface.

zonecfg:my-zone> add net

(shared-IP only) Set the IP address
for the network interface, 192.168.0.1 in this procedure.

zonecfg:my-zone:net> set address=192.168.0.1

Set the physical device type for the
network interface, the hme device in this procedure.

zonecfg:my-zone:net> set physical=hme0

(Optional, shared-IP only) Set the default router for the network
interface, in this procedure.

zonecfg:my-zone:net> set defrouter=10.0.0.1

End the specification.

zonecfg:my-zone:net> end

This step can be performed more than once to add more than one network
interface.

Add a device.

zonecfg:my-zone> add device

Set the device match, /dev/sound/* in this procedure.

zonecfg:my-zone:device> set match=/dev/sound/*

End the device specification.

zonecfg:my-zone:device> end

This step can be performed more than once to add more than one device.

Add a zone-wide resource control by
using the property name.

zonecfg:my-zone> set max-sem-ids=10485200

This step can be performed more than once to add more than one resource
control.

Add a comment by using the attr resource
type.

zonecfg:my-zone> add attr

Set the name to comment.

zonecfg:my-zone:attr> set name=comment

Set the type to string.

zonecfg:my-zone:attr> set type=string

Set the value to a comment that describes
the zone.

zonecfg:my-zone:attr> set value="This is my work zone."

End the attr resource
type specification.

zonecfg:my-zone:attr> end

Verify the zone configuration for the
zone.

zonecfg:my-zone> verify

Commit the zone configuration for the
zone.

zonecfg:my-zone> commit

Exit the zonecfg command.

zonecfg:my-zone> exit

Note that even if you did not explicitly type commit at
the prompt, a commit is automatically attempted when you
type exit or an EOF occurs.

Using Multiple Subcommands From the Command Line

Tip –

The zonecfg command also supports multiple subcommands,
quoted and separated by semicolons, from the same shell invocation.

This chapter discusses zone installation on your Solaris system. It
also describes the two processes that manage the virtual platform and the
application environment, zoneadmd and zsched.
Information about halting, rebooting, cloning, and uninstalling zones is also
provided.

Zone Installation and Administration Concepts

The zoneadm command described in the zoneadm(1M) man page
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 the zoneadm command:

Verify a zone

Install a zone

Change the state of an installed zone to incomplete

Boot a zone, which is similar to booting a regular Solaris
system

Display information about a running zone

Halt a zone

Reboot a zone

Uninstall a zone

Relocate a zone from one point on a system to another point
on the same system

Provision a new zone based on the configuration of an existing
zone on the same system

Zone Construction

This section applies to initial zone construction, and not to the cloning
of existing zones.

After
you have configured a non-global zone, you should verify that the zone can
be installed safely on your system's configuration. You can then install the
zone. The files needed for the zone's root file system are installed by the
system under the zone's root path.

The method used to initially install packages in a Solaris installation
is also the method used to populate a non-global zone.

The global zone must contain all the data necessary to populate a non-global
zone. Populating a zone includes creating directories, copying files, and
providing configuration information.

Only the information or data that was created in the global zone from
packages is used to populate the zone from the global zone. For more information,
see the pkgparam(1) and pkginfo(4) man pages.

Data from the following are not referenced or copied when a zone is
installed:

Non-installed packages

Patches

Data on CDs and DVDs

Network installation images

Any prototype or other instance of a zone

In addition, the following types of information, if present in the global
zone, are not copied into a zone that is being installed:

New or changed users in the /etc/passwd file

New or changed groups in the /etc/group file

Configurations for networking services such as DHCP address
assignment

Customizations for networking services such as UUCP or sendmail

Configurations for network services such as naming services

New or changed crontab, printer, and mail
files

System log, message, and accounting files

If Solaris auditing is used, modifications to auditing files copied
from the global zone might be required. For more information, see Using Solaris Auditing in Zones.

The following features cannot be configured in a non-global zone:

Solaris Live UpgradeTM boot environments

Solaris Volume Manager metadevices

DHCP address assignment in a shared-IP zone

SSL proxy server

The resources specified in the configuration file are added when the
zone transitions from installed to ready. A unique zone ID is assigned by
the system. File systems are mounted, network interfaces are set up, and devices
are configured. Transitioning into the ready state prepares the virtual platform
to begin running user processes. In the ready state, the zsched and zoneadmd processes are started to manage the virtual platform.

zsched, a system scheduling process similar
to sched, is used to track kernel resources associated
with the zone.

zoneadmd is the zones administration daemon.

A zone in the ready state does not have any user processes executing
in it. The primary difference between a ready zone and a running zone is that
at least one process is executing in a running zone. See the init(1M) man page for more information.

The zoneadmd Daemon

The zones administration daemon, zoneadmd,
is the primary process for managing the zone's virtual platform. The daemon
is also responsible for managing zone booting and shutting down. There is
one zoneadmd process running for each active (ready, running,
or shutting down) zone on the system.

The zoneadmd daemon sets up the zone as specified
in the zone configuration. This process includes the following actions:

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

Setting up network interfaces

Mounting loopback and conventional file systems

Instantiating and initializing the zone console device

Unless the zoneadmd daemon is already running, it
is automatically started by zoneadm. Thus, if the daemon
is not running for any reason, any invocation of zoneadm
to administer the zone will restart zoneadmd.

The man page for the zoneadmd daemon is zoneadmd(1M).

The zsched Zone Scheduler

An active zone is a zone that is in the ready state, the running
state, or the shutting down state. Every active zone has an associated kernel
process, zsched. Kernel threads doing work on behalf of
the zone are owned by zsched. The zsched process
enables the zones subsystem to keep track of per-zone kernel threads.

Zone Application Environment

The zoneadm command is used to create the zone application
environment.

After a non-global zone is booted for the first time, the internal configuration
of the zone must be created. The internal configuration specifies a naming
service to use, the default locale and time zone, the zone's root password,
and other aspects of the application environment. For more information, see Internal Zone Configuration and Performing the Initial Internal Zone Configuration.
Note that the default locale and time zone for a zone can be configured independently
of the global settings.

About Halting, Rebooting, and Uninstalling
Zones

This section provides an overview of the procedures for halting, rebooting,
uninstalling, and cloning zones.

Halting a Zone

The zoneadmhalt 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 destroyed, file
systems are unmounted, and the kernel data structures are destroyed.

Rebooting a Zone

The zoneadmreboot command is used to reboot a zone. The
zone is halted and then booted again. The zone ID will change when the zone
is rebooted.

Zone Boot Arguments

Zones support the following boot arguments used with the zoneadmboot and reboot commands:

-ialtinit

-msmf_options

-s

The following definitions apply:

-ialtinit

Selects an alternative executable to be the first process. altinit must be a valid path to an executable. The default first
process is described in init(1M).

-msmf_options

Controls the boot behavior of SMF. There are two categories
of options, recovery options and messages options. Message options determine
the type and number of messages that displays during boot. Service options
determine the services that are used to boot the system.

Recovery options include the following:

debug

Prints standard per-service output and all svc.startd messages
to log.

milestone=milestone

Boot to the subgraph defined by the given milestone. Legitimate
milestones are none, single-user, multi-user, multi-user-server, and all.

Zone autoboot

If you set the autoboot resource property in a zone's
configuration to true, that zone is automatically booted
when the global zone is booted. The default setting is false.

Note that for zones to autoboot, the zones service svc:/system/zones:default must also be enabled.

Uninstalling a Zone

The zoneadmuninstall command
is used to uninstall all of the files under the zone's root file system. Before
proceeding, the command prompts you to confirm the action, unless the -F (force)
option is also used. Use the uninstall command with caution,
because the action is irreversible.

About Cloning Non-Global Zones

Cloning allows you to copy an existing configured and installed zone
on your system to rapidly provision a new zone on the same system. Note that
at a minimum, you must reset properties and resources for the components that
cannot be identical for different zones. Thus, the zonepath must
always be changed. In addition, for a shared-IP zone, the IP addresses in
any net resources must be different. For an exclusive-IP zone, the physical
property of any net resources must be different.

Cloning a zone is a faster way to install a zone.

The new zone will include any changes that have been made
to customize the source zone, such as added packages or file modifications.

When the source zonepath and the target zonepath both reside on ZFS and are in the same pool, the zoneadmclone command automatically uses ZFS to clone the zone. When using
ZFS clone, the data is not actually copied until it is modified. Thus, the
initial clone takes very little time. The zoneadm command
takes a ZFS snapshot of the source zonepath, and sets up
the target zonepath. The system names the snapshot SUNWzoneX, where X is
a unique ID used to distinguish between multiple snapshots. The zonepath of the destination zone is used to name the ZFS clone. A software
inventory is performed so that a snapshot used at a future time can be validated
by the system. To clone a source zone multiple times, the zoneadm command
allows you to specify that an existing snapshot should be used. The system
validates that the existing snapshot is usable on the target.

You might want to
clone a source zone many times but not want to have a new snapshot for each
clone. The -s parameter to the clone subcommand
allows you to specify that an existing snapshot taken from a previous clone
should be used. See How to Clone a Zone from an Existing Snapshot.

Because a snapshot's contents represent a zone
from a point in the past, it is possible that the system has been updated
in some way, such as by patching or upgrading, since the snapshot was taken.
The fact that the zone was upgraded could render the snapshot invalid for
use as a zone on the present-day system.

Note –

You can specify that a ZFS zonepath be copied
instead of ZFS cloned, even though the source could be cloned in this way.

This chapter describes how to install and boot a non-global zone. A
method for using cloning to install a zone on the same system is also provided.
Other tasks associated with installation, such as halting, rebooting, and
uninstalling zones, are addressed. The procedure to completely delete a zone
from a system is also included.

Booting a zone places the zone in the running state. A zone can be booted
from the ready state or from the installed state. Note that you must perform
the internal zone configuration when you log in to the zone after booting
it for the first time.

Installing and Booting Zones

Use
the zoneadm command described in the zoneadm(1M) man
page to perform installation tasks for a non-global zone. You must be the
global administrator to perform the zone installation. The examples in this
chapter use the zone name and zone path established in Configuring, Verifying, and Committing a Zone.

(Optional) How to Verify a Configured Zone
Before It Is Installed

You
can verify a zone prior to installing it. One of the checks performed is a
check for sufficient disk size. If you skip this procedure, the verification
is performed automatically when you install the zone.

You must be the global administrator in the global zone to perform this
procedure.

Verify a configured zone named my-zone by using the -z option with the name of the zone
and the verify subcommand.

global# zoneadm -z my-zone verify

This message regarding verification of the zone path will be displayed:

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

However, 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.

How to Install a Configured Zone

This procedure is used
to install a configured non-global zone.

You must be the global administrator in the global zone to perform this
procedure.

Note –

In Step 2, if the zonepath is
on ZFS, the zoneadminstall command
automatically creates a ZFS file system (dataset) for the zonepath when
the zone is installed. You can block this action by including the -xnodataset parameter.

How to Obtain the UUID of an Installed Non-Global
Zone

A
universally unique identifier (UUID) is assigned to a zone when it is installed.
The UUID can be obtained by using zoneadm with the list subcommand and the -p option. The UUID is the fifth
field of the display.

Example 19–1 How to Use the Zone UUID in a Command

If both -uuuid-match and -zzonename are present, the match is done
based on the UUID first. If a zone with the specified UUID is found, that
zone is used, and the -z parameter is ignored. If no zone
with the specified UUID is found, then the system searches by the zone name.

About the UUID

Zones can be uninstalled and reinstalled under the same name with different
contents. Zones can also be renamed without the contents being changed. For
these reasons, the UUID is a more reliable handle than the zone name.

How to Boot a Zone

Booting a zone
places the zone in the running state. A zone can be booted from the ready
state or from the installed state. A zone in the installed state that is booted
transparently transitions through the ready state to the running state. Zone
login is allowed for zones in the running state.

Example 19–2 Specifying Boot Arguments for Zones

Zone administrator reboot of the zone my-zone,
using the -mverbose option:

my-zone# reboot -- -m verbose

Troubleshooting

If a message indicating that the system was unable to find the netmask
to be used for the IP address specified in the zone's configuration displays,
see netmasks Warning Displayed When Booting Zone.
Note that the message is only a warning and the command has succeeded.

How to Boot a Zone in Single-User Mode

You must be the global administrator in the global zone to perform
this procedure.

The halt procedure is used to remove both the application environment
and the virtual platform for a zone. The procedure returns a zone in the ready
state to the installed state. To cleanly shut down a zone, see How to Use zlogin to Shut Down a Zone.

Use the zoneadm command
with the -zuninstall option to remove
the zone my-zone.

You can also use the -F option
to force the action. If this option is not specified, the system will prompt
for confirmation.

global# zoneadm -z my-zone uninstall -F

Note that when you uninstall a zone that has its own ZFS file system
for the zonepath, the ZFS file system is destroyed.

List the zones on the system again, to
verify that my-zone is no longer listed.

global# zoneadm list -iv

You will see a display that is similar to the following:

ID NAME STATUS PATH BRAND IP
0 global running / native shared

Troubleshooting

If a zone uninstall is interrupted, the zone is left in the incomplete
state. Use the zoneadmuninstall command
to reset the zone to the configured state.

Use the uninstall command with caution because the
action is irreversible.

Cloning a Non-Global Zone on the Same System

Cloning is used to provision a new zone
on a system by copying the data from a source zonepath to
a target zonepath.

When the source zonepath and the target zonepath both reside on ZFS and are in the same pool, the zoneadmclone command automatically uses ZFS to clone the zone. However,
you can specify that the ZFS zonepath be copied and not
ZFS cloned.

How to Clone a Zone

You must configure the new zone before you can install it. The parameter
passed to the zoneadmcreate subcommand
is the name of the zone to clone. This source zone must be halted.

You must be the global administrator in the global zone to perform this
procedure.

Halt the source zone to be cloned, which is my-zone in
this procedure.

global# zoneadm -z my-zone halt

Start configuring the new zone by exporting the configuration
of the source zone my-zone to a file, for example, master.

global# zonecfg -z my-zone export -f /export/zones/master

Note –

You can also create the new zone configuration using the procedure How to Configure the Zone instead of modifying
an existing configuration. If you use this method, skip ahead to Step 6 after
you create the zone.

Edit the file master. Set different properties
and resources for the components that cannot be identical for different zones.
For example, you must set a new zonepath. For a shared-IP
zone, the IP addresses in any net resources must be changed. For an exclusive-IP
zone, the physical property of any net resources must be changed.

Create the new zone, zone1, by using the commands
in the file master.

global# zonecfg -z zone1 -f /export/zones/master

Install the new zone, zone1, by cloning my-zone.

global# zoneadm -z zone1 clone my-zone

The system displays:

Cloning zonepath /export/home/my-zone...

If the source zonepath is on a ZFS pool, for example, zeepool, the system displays:

Cloning snapshot zeepool/zones/my-zone@SUNWzone1
Instead of copying, a ZFS clone has been created for this zone.

zlogin Command

After you install a zone, you must log in to the zone to complete
its application environment. You might log in to the zone to perform administrative
tasks as well. Unless the -C option is used to connect to
the zone console, logging in to a zone using zlogin starts
a new task. A task cannot span two zones.

The zlogin command is used to log in from the global
zone to any zone that is in the running state or the ready state.

Note –

Only the zlogin command with the -C option
can be used to log in to a zone that is not in the running state.

As described in How to Use Non-Interactive Mode to Access a Zone, you can use the zlogin command
in non-interactive mode by supplying a command to run inside a zone. However,
the command or any files the command acts upon cannot reside on NFS. The command
will fail if any of its open files or any portion of its address space resides
on NFS. The address space includes the command executable itself and the command's
linked libraries.

The zlogin command can only be used by the global
administrator operating in the global zone. See the zlogin(1) man page for
more information.

Internal Zone Configuration

After installation, the zone is in an unconfigured state. The
zone does not have an internal configuration for naming services, its locale
and time zone have not been set, and various other configuration tasks have
not been performed. Therefore, the sysidtool programs are
run the first time a zone is booted. For more information, see the sysidtool(1M) man page.

Two methods are available for performing the required configuration:

Zone console login, which initiates a series of questions
from the system. Be prepared to respond to the following:

An /etc/sysidcfg file, which you can
create and place inside the zone before you boot the zone for the first time.
See the sysidcfg(4) man
page for more information.

Non-Global Zone Login Methods

This section describes the methods you can use to log in to a zone.

Zone Console Login

Each zone maintains a virtual console, /dev/console. Performing actions on the console is referred to as console mode.
Console login to a zone is available when the zone is in the installed state.
The zone console is closely analogous to a serial console on a system. Connections
to the console persist across zone reboots. To understand how console mode
differs from a login session such as telnet, see Remote Login.

The zone console is accessed by using the zlogin command
with the -C option and the zonename.
The zone does not have to be in the running state.

Processes inside the zone can open and write messages to the console.
If the zlogin-C process exits, another
process can then access the console.

User Login Methods

To log in to the zone with a user name, use the zlogin command
with the -l option, the user name, and the zonename.
For example, the administrator of the global zone can log in as a normal user
in the non-global zone by specifying the -l option to zlogin:

global# zlogin -l userzonename

To log in as user root, use the zlogin command
without options.

Failsafe Mode

If a login problem occurs and you cannot use the zlogin command
or the zlogin command with the -C option
to access the zone, an alternative is provided. You can enter the zone by
using the zlogin command with the -S (safe)
option. Only use this mode to recover a damaged zone when other forms of login
are not succeeding. In this minimal environment, it might be possible to diagnose
why the zone login is failing.

Remote Login

The
ability to remotely log in to a zone is dependent on the selection of network
services that you establish. By default, a non-global zone is installed with
the limited networking configuration (/var/svc/profile/generic_limited_net.xml), and only the ssh login is enabled. Logins
through rlogin and telnet can be added
if needed, either by using the netservices command to switch
the zone to the open networking configuration or by enabling the services
using SMF.

Interactive and Non-Interactive Modes

Two other methods for accessing the zone and for executing commands
inside the zone are also provided by the zlogin command.
These methods are interactive mode and non-interactive mode.

Interactive Mode

In interactive mode, a new pseudo-terminal is allocated for use
inside the zone. Unlike console mode, in which exclusive access to the console
device is granted, an arbitrary number of zlogin sessions
can be open at any time in interactive mode. Interactive mode is activated
when you do not include a command to be issued. Programs that require a terminal
device, such as an editor, operate correctly in this mode.

Non-Interactive Mode

Non-interactive mode is used to run shell-scripts which administer
the zone. Non-interactive mode does not allocate a new pseudo-terminal. Non-interactive
mode is enabled when you supply a command to be run inside the zone.

Chapter 21 Logging In to Non-Global Zones (Tasks)

This chapter provides procedures for completing the configuration of
an installed zone, logging into a zone from the global zone, and shutting
down a zone. This chapter also shows how to use the zonename command
to print the name of the current zone.

You can log into a zone through the console, by using interactive mode
to allocate a pseudo-terminal, or by supplying a command to be run in the
zone. Supplying a command to be run does not allocate a pseudo-terminal. You
can also log in by using failsafe mode when a connection to the zone is denied.

After you have performed the internal configuration, it is a good
idea to make a copy of the non-global zone's configuration. You can use this
backup to restore the zone in the future. As superuser or Primary Administrator,
print the configuration for the zone my-zone to a file.
This example uses a file named my-zone.config.

(Optional) If you are not using two
windows as described in step 3, you might have missed the initial prompt for
configuration information. If you see the following system message at zone
login instead of a prompt:

[connected to zone zonename console]

Press Return to display the prompt again.

If you enter an incorrect response and try to restart the configuration,
you might experience difficulty when you attempt the process again. This occurs
because the sysidtools can store your previous responses.

If this happens, use the following workaround from the global zone to
restart the configuration process.

global# zlogin -S zonename /usr/sbin/sys-unconfig

For more information on the sys-unconfig command,
see the sys-unconfig(1M) man page.

How to Use an /etc/sysidcfg File
to Perform the Initial Zone Configuration

You must be the global administrator in the global zone to perform this
procedure.

If you are running an earlier release and do not have the nfs4_domain parameter in your file, by default, a separate module will request
the NFSv4 domain parameter used by the nfsmapid command.
To complete a hands-off initial zone configuration, edit the file default/nfs, uncomment the NFSMAPID_DOMAIN parameter, and
set the domain to the desired NFSv4 domain:

global# vi default/nfs
.
.
.
NFSMAPID_DOMAIN=domain

Create the file .NFS4inst_state.domain in this
directory to indicate that the NFSv4 domain has been set:

global# touch .NFS4inst_state.domain

For more information on the NFSv4 domain parameter, see the nfsmapid(1M) man page.

From the global zone, use the zlogin command with the -S option to access the zone,
for example, my-zone.

global# zlogin -S my-zone

How to Use zlogin to
Shut Down a Zone

Note –

Running init0 in the global
zone to cleanly shut down a Solaris system also runs init0 in each of the non-global zones on the system. Note that init0 does not warn local and remote users to log
off before the system is taken down.

Use this procedure to cleanly shut down a zone. To halt a zone without
running shutdown scripts, see How to Halt a Zone.

You must be the global administrator in the global zone to perform this
procedure.

Printing the Name of the Current Zone

The zonename command described in the zonename(1) man
page prints the name of the current zone. The following example shows the
output when zonename is used in the global zone.

# zonename
global

Chapter 22 Moving and Migrating Non-Global Zones (Tasks)

This chapter describes how to:

Move an existing non-global zone to a new location on the
same machine.

Validate what will happen in a non-global zone migration before
the actual migration is performed.

Migrate an existing non-global zone to a new machine.

If the new host
has later versions of the zone-dependent packages or the associated patches,
using zoneadmattach with the -u option
updates those packages within the zone to match the new host. If the new host
has a mixture of higher and lower version patches as compared to the source
host, then an update during the attach operation is not allowed.

The -u option enables migration between machine classes, such as from sun4u to sun4v.

The -b option
can be used to specify patches, either official or Interim Diagnostics/Relief
(IDR), to be backed out of the zone before the update. Multiple -b options
can be specified. If any of the patches cannot be backed out for any reason,
then the attach will fail and none of the patches will
be backed out.

Moving a Non-Global Zone

This procedure is used to move the zone to a new location on the same
system by changing the zonepath. The zone must be halted.
The new zonepath must be on a local file system. The normal zonepath criteria described in Resource and Property Types apply.

How to Move a Zone

You must be the global administrator in the global zone to perform this
procedure.

About Migrating a Zone

The zonecfg and zoneadm commands can be used to migrate
an existing non-global zone from one system to another. The zone is halted
and detached from its current host. The zonepath is moved
to the target host, where it is attached.

The following requirements apply to zone migration:

The global zone on the target system must be running the same
Solaris release as the original host.

To ensure that the zone will run properly, the target system
must have the same or later versions of the following required operating system
packages and patches as those installed on the original host.

Packages that deliver files under an inherit-pkg-dir resource

Packages where SUNW_PKG_ALLZONES=true

Other packages and patches, such as those for third-party products,
can be different.

If the new host has later versions of the zone-dependent packages
or their associated patches, using zoneadmattach with
the -u option updates those packages within the zone to match
the new host. The update
on attach software looks at the zone that is being migrated and determines
which packages must be updated to match the new host. Only those packages
are updated. The rest of the packages, and their associated patches, can vary
from zone to zone. This option also enables automatic migration between sun4u and sun4v machine classes. The -b option
can be used to specify patches to be backed out of the zone before the update.

The host and target systems must have the same machine architecture unless the -u option,
which can be used to migrate between sun4u and sun4v machine
classes, is used.

The -b option can be used to specify patches, either official or IDR, to
be backed out of the zone before the update. Multiple -b options
can be specified. If any of the patches cannot be backed out for any reason,
then the attach will fail and none of the patches will
be backed out.

This new option is brand-specific and only applies
to zone brands using SVR4 packaging.

To verify the Solaris release and the machine architecture, type:

#uname -m

The zoneadmdetach process creates
the information necessary to attach the zone on a different system. The zoneadmattach process verifies that the target
machine has the correct configuration to host the zone.

Because there are several ways to make the zonepath available
on the new host, the actual movement of the zonepath from
one system to another is a manual process that is performed by the global
administrator.

When attached to the new system, the zone is in the installed state.

How to Migrate A Non-Global Zone

You must be the global administrator in the global zone to perform this
procedure.

The system administrator is notified of required actions to be taken
if either or both of the following conditions are present:

Required packages and patches are not present on the new machine.

The software levels are different between machines.

Attach the zone with a validation
check and update the zone to match a host running later
versions of the dependent packages or having a different machine class upon
attach.

host2# zoneadm -z my-zone attach -u

Tip –

If the source system is running an older version of the Solaris
system, it might not generate a correct list of packages when the zone is
detached. To ensure that the correct package list is generated on the destination,
you can remove the SUNWdetached.xml file from the zonepath. Removing this
file will cause a new package list to be generated by the destination system.

Also
use the -b option to back out specified patches, either official
or IDR, before the update.

host2# zoneadm -z my-zone attach -u -b IDR246802-01 -b123456-08

Note that you can use the -b option independently of
the -u option.

Force the attach operation without performing the validation.

host2# zoneadm -z my-zone attach -F

Caution –

The -F option allows you to force the attach with no validation performed. This is useful in certain cases,
such as in a clustered environment or for backup and restore operations, but
it does require that the system be properly configured to host the zone. An
incorrect configuration could result in undefined behavior later.

How to Move the zonepath to a new
Host

There are many ways to create an archive of the zonepath.
For example, you can use the cpio or pax commands
described in the cpio(1))
and pax(1) man
pages.

There are also several ways to transfer the archive to the new host.
The mechanism used to transfer the zonepath from the source
host to the destination depends on the local configuration. In some cases,
such as a SAN, the zonepath data might not actually move.
The SAN might simply be reconfigured so the zonepath is
visible on the new host. In other cases, the zonepath might
be written to tape, and the tape mailed to a new site.

For these reasons, this step is not automated. The system administrator
must choose the most appropriate technique to move the zonepath to
the new host.

Troubleshooting

Next Steps

If you have copied the data instead of reconfiguring a SAN, then the zonepath data will still be visible on the source host even though
the zone is now in the configured state. You can either manually remove the zonepath from the source host after you have finished moving the
data to the new host, or you can reattach the zone to the source host and
use the zoneadmuninstall command to
remove the zonepath.

About Validating a Zone Migration Before the Migration
Is Performed

You
can perform a trial run before the zone is moved to the new machine by using
the “no execute” option,-n.

The zoneadmdetach subcommand
is used with the -n option to generate a manifest on a running
zone without actually detaching the zone. The state of the zone on the originating
system is not changed. The zone manifest is sent to stdout.
The global administrator can direct this output to a file or pipe it to a
remote command to be immediately validated on the target host. The zoneadmattach subcommand is used with the -n option
to read this manifest and verify that the target machine has the correct configuration
to host the zone without actually doing an attach.

The zone on the target system does not have to
be configured on the new host before doing a trial-run attach.

How to Validate a Zone Migration Before the Migration
Is Performed

You must be the global administrator in the global zone to perform this
procedure.

Migrating a Zone From a Machine That Is not Usable

A machine that hosts a native Solaris zone
can become unusable. However, if the storage the zone lives on, such as a
SAN, is still usable, it might still be possible to migrate the zone to a
new host successfully. You can move the zonepath for the
zone to the new host. In some cases, such as a SAN, the zonepath data
might not actually move. The SAN might simply be re-configured so the zonepath is visible on the new host. Since the zone was not properly detached,
you will have to first create the zone on the new host using the zonecfg command. Once this has been done, attach the zone on the new host.
Although the new host will tell you the zone was not properly detached, the
system will attempt the attach anyway.

Chapter 23 SX Only: Migrating a Physical Solaris System Into
a Zone (Tasks)

A "physical to virtual" (P2V) capability is used to directly migrate
an existing Solaris system into a native zone on a target system. This feature
is not currently available on OpenSolaris 2009.06 systems.

Assess the System To Be Migrated

The
system image to be installed through P2V must not be newer than the target
host operating system release, or the installation will fail.

Depending on the services performed by the original system, the global
administrator might need to manually customize the zone after it has been
installed. For example, the privileges assigned to the zone might need to
be modified. This is not done automatically. Also, because all system services
do not work inside zones, not every physical system is a good candidate for
migration into a zone.

In some cases, flarcreate can display errors
from the cpio command. Most commonly, these are messages
such as File size of etc/mnttab has increased by 33. When
these messages pertain to log files or files that reflect system state, they
can be ignored. Be sure to review all error messages thoroughly.

Other Archive Creation Methods

You can use alternate methods for creating the archive. The installer
can accept the following archive formats:

cpio archives

gzip compressed cpio archives

bzip2 compressed cpio archives

pax archives created with the -xxustar (XUSTAR) format

ufsdump level zero (full) backups

Additionally, the installer can accept a directory of files created
by using an archiving utility that saves and restores file permissions, ownership,
and links. Thus, an example of a utility that cannot be used is tar,
because tar does not handle links.

Host ID Emulation

When applications are migrated from a standalone Solaris system
into a zone on a new system, the hostid changes to be the hostid of the new machine.

In some cases, applications depend on the original hostid,
and it is not possible to update the application configuration. In these cases,
the zone can be configured to use the hostid of the original
system. This is done by setting a zonecfg property to specify
the hostid, as described in How to Configure the Zone. The value used should be the output of
the hostid command as run on the original system. To view
the hostid in an installed zone, also use the hostid command.

Configure the Source Zone

If you know you will be using CDs or DVDs to install applications
in the new zone, use addfs to add read-only
access to CD or DVD media in the global zone when you initially configure
the branded zone. A CD or DVD can then be used to install a product in the
branded zone. See How to Add Access to CD or DVD Media in a Non-Global Zone for more information.

Install the Zone

The zoneadm command described earlier in this guide
and in the zoneadm(1M) man
page is the primary tool used to install and administer non-global zones.
Operations using the zoneadm command must be run from the
global zone on the target system.

In addition to unpacking files from the archive, the install process
performs checks, required postprocessing, and other functions to ensure that
the zone is optimized to run on the host.

If you created a Solaris system archive from an existing system and
use the -p (preserve sysidcfg) option when
you install the zone, then the zone will have the same identity as the system
used to create the image.

If you use the -u (sys-unconfig)
option when you install the target zone, the zone produced will not have a
hostname or name service configured.

Caution –

You must use either the -p option
or the -u option. If you do not specify one of these two options,
an error results.

Installer Options

Option

Description

-a

Location of archive from which to copy system image. Full flash archive
and cpio, gzip compressed cpio, bzip compressed cpio, and level 0 ufsdump are
supported. Refer to the gzip man page available in the SUNWsfman package.

-dpath

Location of directory from which to copy system image.

-d—

Use the -d option with the dash parameter to direct
that the existing directory layout be used in the zonepath.
Thus, if the administrator manually sets up the zonepath directory
before the installation, the -d— option
can be used to indicate that the directory already exists.

-p

Preserve system identity.

-s

Install silently.

-u

sys-unconfig the zone.

-v

Verbose output.

The -a and -d options are mutually exclusive.
The -p, -s, -u and -v options
are only allowed when either -a or -d is provided.

How to Install the Zone

Become superuser, or assume the Primary Administrator role.

Install the configured zone s-zone by using
the zoneadm command with the install-a option and the path to the archive.

You will see various messages as the installation completes. This can
take some time.

When the installation completes, use the list subcommand
with the -i and -v options to list the installed
zones and verify the status.

Troubleshooting

If an installation fails, review the log file. On success, the log file
is in two places: /var/tmp in the global zone, and /var/log inside the zone. On failure, the log file is in /var/tmp.

If a zone installation is interrupted or fails, the zone is left in
the incomplete state. Use uninstall-F to
reset the zone to the configured state.

Boot the Zone

How to Boot the Zone

You must be the global administrator in the global zone to perform this
procedure.

Become superuser, or assume the Primary Administrator role.

Use the zoneadm command with the -z option, the name of the zone, which is s-zone,
and the boot subcommand to boot the zone.

global# zoneadm -z s-zone boot

When the boot completes, use the list subcommand
with the -v option to verify the status.

global# zoneadm list -v

Chapter 24 About
Packages and Patches on a Solaris System With Zones Installed (Overview)

Both IPS and SVR4
packages are supported for the OpenSolaris 2009.06 release. This
chapter discusses maintaining the Solaris Operating System on a system using
SVR4 packaging when
zones are installed.

Information
about adding packages and patches to the operating system using SVR4 packaging in the
global zone and in all installed non-global zones is provided. Information
about removing packages and patches is also included. The material in this
chapter supplements the existing Solaris installation and patch documentation.
See the Solaris Express Release and Installation Collection and System Administration Guide: Basic Administration for more information.

Image
Packaging System Software Used on Systems Running the OpenSolaris 2009.06
Release

SVR4 Packaging and Patch Tools Overview

The Solaris packaging tools are used in administering the zones
environment. The global administrator can upgrade the system to a new version
of Solaris, which updates both the global and the non-global zones.

Solaris Live Upgrade, the standard Solaris interactive installation
program, or the custom Solaris JumpStart installation program can be used
in the global zone to upgrade a system that includes non-global zones.

The zone administrator can use the packaging tools to administer any
software installed in a non-global zone, within the limits described in this
document.

The following general principles apply when zones are installed:

The global administrator can administer the software on every
zone on the system.

The root file system for a non-global zone can be administered
from the global zone by using the Solaris packaging and patch tools. The Solaris
packaging and patch tools are supported within the non-global zone for administering
co-packaged (bundled), standalone (unbundled), or third-party products.

The packaging and patch tools work in a zones-enabled environment.
The tools allow a package or patch installed in the global zone to also be
installed in a non-global zone.

The SUNW_PKG_ALLZONES package parameter
defines the zone scope of a package. The scope determines
the type of zone in which an individual package can be installed. For more
information about this parameter, see SUNW_PKG_ALLZONES Package Parameter.

The SUNW_PKG_HOLLOW package parameter defines
the visibility of a package if that package is required
to be installed on all zones and be identical in all zones. For information
about this parameter, see SUNW_PKG_HOLLOW Package Parameter.

The SUNW_PKG_THISZONE package parameter
defines whether a package must be installed in the current zone only. For
information about this parameter, see SUNW_PKG_THISZONE Package Parameter.

Packages that do not define values for zone package parameters
have a default setting of false.

The packaging information visible from within a non-global
zone is consistent with the files that have been installed in that zone using
the Solaris packaging and patch tools. The visibility includes packages that
have been imported from the global zone using read-only loopback mounts.
See Configuring, Verifying, and Committing a Zone for more information about this process.

A change, such as a patch or package added in the global zone,
can be pushed out to all of the zones. This feature maintains consistency
between the global zone and each non-global zone.

The package commands can add, remove, and interrogate packages.
The patch commands can add and remove patches.

Note –

While certain package and patch operations are performed, a zone
is temporarily locked to other operations of this type. The system might also
confirm a requested operation with the administrator before proceeding.

About SVR4 Packages and Zones

Only a subset of the Solaris packages installed on the global zone are
completely replicated when a non-global zone is installed. For example, many
packages that contain the Solaris kernel are not needed in a non-global zone.
All non-global zones implicitly share the same Solaris kernel from the global
zone. However, even if a package's data is not required or is not of use in
a non-global zone, the knowledge that a package is installed in the global
zone might be required in a non-global zone. The information allows package
dependencies from the non-global zones to be properly resolved with the global
zone.

Packages have parameters that control how their content is distributed
and made visible on a system with non-global zones installed. The SUNW_PKG_ALLZONES, SUNW_PKG_HOLLOW, and SUNW_PKG_THISZONE package
parameters define the characteristics of packages on a system with zones installed.
If desired, system administrators can check these package parameter settings
to verify the package's applicability when applying or removing a package
in a zone environment. The pkgparam command can be used
to view the values for these parameters. For more information on parameters,
see Package Parameter Information (SVR4 Only). See Checking Package Parameter Settings on a System with Zones Installed for usage instructions.

Patches Generated for Packages

When
a patch is generated for any package, the parameters must be set to the same
values as the original package.

Interactive Packages

Any
package that must be interactive, which means that it has a request script,
is added to the current zone only. The package is not propagated to any other
zone. If an interactive package is added to the global zone, the package is
treated as though it is being added by using the pkgadd command
with the -G option. For more information about this option,
see About Adding Packages in Zones (SVR4 Only).

Keeping Zones in Sync With SVR4 Packaging

It
is best to keep the software installed in the non-global zones in sync with
the software installed in the global zone to the maximum extent possible.
This practice minimizes the difficulty in administering a system with multiple
installed zones.

To achieve this goal, the package tools enforce the following rules
when adding or removing packages in the global zone.

Package Operations Possible in the Global
Zone

If the package is not currently installed in the global zone and not
currently installed in any non-global zone, the package can be installed:

Only in the global zone, if SUNW_PKG_ALLZONES=false

In the current zone only, which is the global zone in this
case, if SUNW_PKG_THISZONE=true

In the global zone and all non-global zones

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

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:

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 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 installed in the global zone and also installed in
any non-global zone are the same across all zones.

Package Operations Possible in a Non-Global
Zone

The package operations possible in any non-global zone are:

If a package is not currently installed in the non-global
zone, the package can be installed only if SUNW_PKG_ALLZONES=false.

The package can be installed in the current zone, which is
the non-global zone in this case, if SUNW_PKG_THISZONE=true.

If a package is currently installed in the non-global zone:

The package can be installed over the existing instance of
the package only if SUNW_PKG_ALLZONES=false.

The package can be removed from the non-global zone only if SUNW_PKG_ALLZONES=false.

How Zone State Affects Patch and Package Operations With SVR4 Packaging

The following table describes what will happen when pkgadd, pkgrm, patchadd, and patchrm commands
are used on a system with non-global zones in various states.

Zone State

Effect on Package and Patch Operations

Configured

Patch and package tools can be run. No software has been installed yet.

Installed

Patch and package tools can be run. During patch or packaging operations,
the system moves a zone from the installed state to a new internal state called
mounted. After patching has completed, the zone is reverted back to the installed
state.

Note that immediately after zoneadm-zzonenameinstall has completed, the zone
is also moved to the installed state. A zone in the installed state that has
never been booted cannot be patched or run packaging commands. The zone must
be booted to the running state at least once. After a zone has been booted
at least once, and then moved back to the installed state by using zoneadmhalt, then patch and packaging commands can
be run.

Ready

Patch and package tools can be run.

Running

Patch and package tools can be run.

Incomplete

A zone being installed or removed by zoneadm. Patch
and package tools cannot be used. The tools cannot bring the zone into the
appropriate state for using the tools.

About Adding Packages in Zones (SVR4 Only)

The pkgadd system utility described in the pkgadd(1M) man page
is used to add packages on a Solaris system with zones installed.

On the OpenSolaris 2009.06
release, use the pkginstall command.

Using pkgadd in the
Global Zone

The pkgadd utility can be used with the -G option
in the global zone to add the package to the global zone only. The package
is not propagated to any other zones. Note that if SUNW_PKG_THISZONE=true, you do not have to use the -G option. If SUNW_PKG_THISZONE=false, the -G option will override it.

When you run the pkgadd utility in the global zone,
the following actions apply.

The pkgadd utility is able to add a package:

To the global zone only, unless the package is SUNW_PKG_ALLZONES=true

To the global zone and to all non-global zones

To all non-global zones only, if the package is already installed
in the global zone

To the current zone only, if SUNW_PKG_THISZONE=true

The pkgadd utility cannot add a package:

To any subset of the non-global zones

To all non-global zones, unless the package is already installed
in the global zone

If the pkgadd utility is run without the -G option and SUNW_PKG_THISZONE=false , the specified
package is added to all zones by default. The package is not marked as installed
in the global zone only.

If the pkgadd utility is run without the -G option and SUNW_PKG_THISZONE=true, then the
specified package is added to the current (global) zone by default. The package
is marked as installed in the global zone only.

If the -G option is used, the pkgadd utility
adds the specified package to the global zone only. The package is marked
as installed in the global zone only. The package is not installed when any
non-global zone is installed.

Adding a Package to the Global Zone and
to All Non-Global Zones

To add a package to the global zone and to all non-global zones, execute
the pkgadd utility in the global zone. As the global administrator,
run pkgadd without the -G option.

A package can be added to the global zone and to all non-global zones
without regard to the area affected by the package.

The following steps are performed by the pkgadd utility:

Package dependencies are checked on the global zone and on
all non-global zones. If required packages are not installed in any zone,
then the dependency check fails. The system notifies the global administrator,
who is prompted whether to continue.

The package is added to the global zone.

The package database on the global zone is updated.

The package is added to each non-global zone and the database
in the global zone is updated.

The package database on each non-global zone is updated.

Adding a Package to the Global Zone Only

To add a package to the global zone only, as the global administrator
in the global zone, execute the pkgadd utility with the -G option only.

A package can be added to the global zone if the following conditions
are true:

The package contents do not affect any area of the global
zone that is shared with any non-global zone.

The package is set SUNW_PKG_ALLZONES=false.

The following steps are performed by the pkgadd utility:

If the package contents affect any area of the global zone
that is shared with any non-global zone, or if the package is set SUNW_PKG_ALLZONES=true, then pkgadd fails. The error message states
that the package must be added to the global zone and to all non-global zones.

Package dependencies are checked on the global zone only.
If required packages are not installed, then the dependency check fails. The
system notifies the global administrator, who is prompted whether to continue.

The package is added to the global zone.

The package database on the global zone is updated.

The package information on the global zone is annotated to
indicate that this package is installed on the global zone only. If a non-global
zone is installed in the future, this package will not be installed.

Adding a Package Installed in the Global
Zone to all Non-Global Zones

To add a package that is already installed in the global zone to all
non-global zones, you must currently remove the package from the global zone
and reinstall it in all zones.

These are the steps used to add a package that is already installed
in the global zone to all of the non-global zones:

In the global zone, use pkgrm to remove
the package.

Add the package without using the -G option.

Using pkgadd in a Non-Global
Zone

To add a package in a specified non-global zone, execute the pkgadd utility, without options, as the zone administrator. The following
conditions apply:

The pkgadd utility can only add packages
in the non-global zone in which the utility is used.

The package cannot affect any area of the zone that is shared
from the global zone.

The package must be set SUNW_PKG_ALLZONES=false.

The following steps are performed by the pkgadd utility:

Package dependencies are checked on the non-global zone's
package database before the package is added. If required packages are not
installed, then the dependency check fails. The system notifies the non-global
zone administrator, who is prompted whether to continue. The check fails if
either of the following conditions are true.

Any component of the package affects any area of the zone
that is shared from the global zone.

The package is set SUNW_PKG_ALLZONES=true.

The package is added to the zone.

The package database on the zone is updated.

About Removing Packages in Zones (SVR4 Only)

The pkgrm utility described in the pkgrm(1M) man page supports removing
packages on a Solaris system with zones installed.

On the OpenSolaris
2009.06 release, use the pkguninstall command.

Using pkgrm in the Global
Zone

The pkgrm utility can be used with the -G option
from the global zone to remove packages from the global zone only. The package
must not affect any area of the global zone shared with non-global zones or
be installed in any non-global zone.

When the pkgrm utility is used in the global zone,
the following actions apply.

pkgrm can remove a package from the global
zone and from all non-global zones, or
from the global zone only when the package is only installed in the global
zone.

pkgrm cannot remove a package only from
the global zone if the package is also installed in a non-global zone, or
remove a package from any subset of the non-global zones.

Note that a package can only be removed from a non-global zone by a
zone administrator working in that zone if the following are true:

The package does not affect any area on the non-global zone
that is shared from the global zone.

The package is set SUNW_PKG_ALLZONES=false.

Removing a Package From the Global Zone
and From all Non-Global Zones

To remove a package from the global zone and from all non-global zones,
execute the pkgrm utility in the global zone. As the global
administrator, run pkgrm without the -G option.

A package can be removed from the global zone and from all non-global
zones without regard to the area affected by the package.

The following steps are performed by the pkgrm utility:

Package dependencies are checked on the global zone and on
all non-global zones. If the dependency check fails, then pkgrm fails.
The system notifies the global administrator, who is prompted whether to continue.

The package is removed from each non-global zone.

The package database on each non-global zone is updated.

The package is removed from the global zone.

The package database on the global zone is updated.

Using pkgrm in a Non-Global
Zone

As the zone administrator, use the pkgrm utility
in a non-global zone to remove a package. The following limitations apply:

pkgrm can only remove packages from the
non-global zone.

The -G option cannot be used. If this option
is used, pkgrm outputs an error message and the attempted
operation fails.

The package cannot affect any area of the zone that is shared
from the global zone.

The package must be set SUNW_PKG_ALLZONES=false.

The following steps are performed by the pkgrm utility:

Dependencies are checked on the non-global zone's package
database. If the dependency check fails, then pkgrm fails
and the zone administrator is notified. The check fails if either of the following
conditions are true.

Any component of the package affects any area of the zone
that is shared from the global zone.

The package is set SUNW_PKG_ALLZONES=true.

The package is removed from the zone.

The package database on the zone is updated.

Package Parameter Information (SVR4 Only)

Setting Package Parameters for Zones

The SUNW_PKG_ALLZONES, SUNW_PKG_HOLLOW,
and SUNW_PKG_THISZONE package parameters define the characteristics
of packages on a system with zones installed. These parameters must be set
so that packages can be administered on a system with non-global zones installed.

The following table lists the four valid combinations for setting package
parameters. If you choose setting combinations that are not listed in the
following table, those settings are invalid and the package will fail to install.

Ensure that you have set all three package parameters. You can leave
all three package parameters blank. The package tools interpret a missing
zone package parameter as if the setting were false, but
not setting the parameters is strongly discouraged. By setting all three
package parameters, you specify the exact behavior the package tools should
exhibit when installing or removing the package.

Table 24–1 Valid Package Parameter
Settings

SUNW_PKG_ALLZONES Setting

SUNW_PKG_HOLLOW Setting

SUNW_PKG_THISZONE Setting

Package Description

false

false

false

This is the default setting for packages that do not specify values
for all the zone package parameters.

A package with these settings can be installed in either the global
zone or a non-global zone.

If the pkgadd command is run in the global
zone, the package is installed in the global zone and in all non-global zones.

If the pkgadd command is run in a non-global
zone, the package is installed in the non-global zone only.

In both cases, the entire contents of the package is visible in all
zones where the package is installed.

false

false

true

A package with these settings can be installed in either the global
zone or a non-global zone. If new non-global zones are created after the
installation, the package is not propagated to these new non-global zones.

If the pkgadd command is run in the global
zone, the package is installed in the global zone only.

If the pkgadd command is run in a non-global
zone, the package is installed in the non-global zone only.

In both cases, the entire contents of the package is visible in the
zone where the package is installed.

true

false

false

A package with these settings can be installed in the global zone only.
When the pkgadd command is run, the package is installed
in the global zone and in all non-global zones. The entire contents of the
package is visible in all zones.

Note –

Any attempt to install the package in a non-global zone fails.

true

true

false

A package with these settings can only be installed in the global zone,
by the global administrator. When the pkgadd command is
run, the contents of the package is fully installed in the global zone. If
a package has the package parameters set to these values, the package content
itself is not delivered on any non-global zone. Only the package installation
information necessary to make the package appear to be installed is installed
on all non-global zones. This enables the installation of other packages to
be installed that depend on this package.

For package dependency checking purposes, the package appears to be
installed in all zones.

In the global zone, the entire contents of the package is
visible.

In whole root non-global zones, the entire contents of the
package is not visible.

When a non-global zone inherits a file system from the global
zone, a package installed in this file system is visible in a non-global
zone. All other files delivered by the package are not visible within the
non-global zone.

For example, a native sparse root non-global zone shares
certain directories with the global zone. These directories are read-only.
Sparse root non-global zones share the /platform file
system among others. Another example is packages that deliver files relevant
only to booting hardware.

Note –

Any attempt to install the package in a non-global zone fails.

SUNW_PKG_ALLZONES Package
Parameter

The optional SUNW_PKG_ALLZONES package parameter
describes the zone scope of a package. This parameter defines the following:

Whether a package is required to be installed on all zones

Whether a package is required to be identical in all zones

The SUNW_PKG_ALLZONES package parameter has two permissible
values. These values are true and false.
The default value is false. If this parameter is either
not set or set to a value other than true or false,
the value false is used.

The SUNW_PKG_ALLZONES parameter should be set to true for packages that must be the same package
version and patch revision level across all zones. Any package that delivers
functionality dependent on a particular Solaris kernel, for example, Solaris
10, should set this parameter to true. Any patch for a
package must set the SUNW_PKG_ALLZONESparameter to the
same value that is set in the installed package being patched. The patch revision
level for any package that sets this parameter to true must
be the same across all zones.

Packages that deliver functionality not dependent on a particular Solaris
kernel, such as third-party packages or Sun compilers, should set this parameter
to false. Any patch for a package that sets this parameter
to false must also set this parameter to false.
Both the package version or the patch revision level for any package that
sets this parameter to false can be different between zones.
For example, two non-global zones could each have a different version of a
web server installed.

The SUNW_PKG_ALLZONES package parameter values are
described in the following table.

Table 24–2 SUNW_PKG_ALLZONES Package
Parameter Values

Value

Description

false

This package can be installed from the global zone to the global zone
only, or to the global zone and to all non-global zones. The package can
also be installed from any non-global zone to the same non-global zone.

The global administrator can install the package on the global
zone only.

The global administrator can install the package on the global
zone and on all non-global zones.

The zone administrator can install the package on a non-global
zone.

If removed from the global zone, the package is not removed from other
zones. The package can be removed from individual non-global zones.

The package is not required to be installed on the global
zone.

The package is not required to be installed on any non-global
zone.

The package is not required to be identical across all zones.
Different versions of the package can exist on individual zones.

The package delivers software that is not implicitly shared
across all zones. This means that the package is not operating system-specific.
Most application-level software is in this category. Examples include the StarOfficeTM product or a web server.

true

If installed on the global zone, this package must also be installed
on all non-global zones. If removed from the global zone, the package must
also be removed from all non-global zones.

If the package is installed, it must be installed on the global
zone. The package is then automatically installed on all non-global zones.

The version of the package must be identical on all zones.

The package delivers software that is implicitly shared across
all zones. The package is dependent on the versions of software that are implicitly
shared across all zones. The package should be visible in all non-global zones.
Examples include kernel modules.

These packages allow the non-global
zone to resolve dependencies on packages that are installed in the global
zone by requiring that the entire package be installed on all non-global
zones.

Only the global administrator can install the package. A zone
administrator cannot install the package on a non-global zone.

SUNW_PKG_HOLLOW Package
Parameter

The SUNW_PKG_HOLLOW package parameter defines
whether a package should be visible in any non-global zone if that package
is required to be installed and be identical in all zones.

The SUNW_PKG_HOLLOW package parameter has two permissible
values, true or false.

If SUNW_PKG_HOLLOW is either not set or
set to a value other than true or false,
the value false is used.

If SUNW_PKG_ALLZONES is set to false,
the SUNW_PKG_HOLLOW parameter is ignored.

If SUNW_PKG_ALLZONES is set to false,
then SUNW_PKG_HOLLOW cannot be set to true.

The SUNW_PKG_HOLLOW package parameter values are
described in the following table.

Table 24–3 SUNW_PKG_HOLLOW Package
Parameter Values

Value

Description

false

This is not a “hollow” package:

If installed on the global zone, the package content and installation
information are required on all non-global zones.

The package delivers software that should be visible in all
non-global zones. An example is the package that delivers the truss command.

Other than the restrictions for the current setting of the SUNW_PKG_ALLZONES package parameter, no additional restrictions
are defined.

true

This is a “hollow” package:

The package content is not delivered on any non-global zone.
However, the package installation information is required on all non-global
zones.

The package delivers software that should not be visible in
all non-global zones. Examples include kernel drivers and system configuration
files that work only in the global zone. This setting allows the non-global
zone to resolve dependencies on packages that are installed only on the global
zone without actually installing the package data.

The package is recognized as being installed in all zones
for purposes of dependency checking by other packages that rely on this package
being installed.

This package setting includes all of the restrictions defined
for setting SUNW_PKG_ALLZONES to true.

In the global zone, the package is recognized as having been
installed, and all components of the package are installed. Directories are
created, files are installed, and class action and other scripts are run as
appropriate when the package is installed.

In a non-global zone, the package is recognized as having
been installed, but no components of the package are installed. No directories
are created, no files are installed, and no class action or other install
scripts are run when the package is installed.

When the package is removed from the global zone, the system
recognizes that the package was completely installed. Appropriate directories
and files are removed, and class action or other install scripts are run when
the package is removed.

SUNW_PKG_THISZONE Package Parameter

The SUNW_PKG_THISZONE package parameter defines
whether a package must be installed in the current zone, global or non-global,
only. The SUNW_PKG_THISZONE package parameter has two permissible
values. These values are true and false.
The default value is false.

The SUNW_PKG_THISZONE package parameter values are
described in the following table.

Table 24–4 SUNW_PKG_THISZONE Package
Parameter Values

Value

Description

false

If pkgadd is run in a non-global zone,
the package is installed in the current zone only.

If pkgadd is run in the global zone, the
package is installed in the global zone and also installed in all currently
installed non-global zones. In addition, the package will be propagated to
all future, newly installed non-global zones.

true

The package is installed in the current zone only.

If installed in the global zone, the package is not added
to any currently existing or yet-to-be-created non-global zones. This is the
same behavior that occurs when the -G option is specified
to pkgadd.

Package Information Query

The pkginfo utility described in the pkginfo(1) man page supports
querying the software package database on a Solaris system with zones installed.
For information about the database, see Product Database (SVr4 Only).

The pkginfo utility can be used in the global zone
to query the software package database in the global zone only. The pkginfo utility can be used in a non-global zone to query the software
package database in the non-global global zone only.

On the OpenSolaris
2009.06 release, use the pkginfo command.

About Adding Patches in Zones (SVR4 Only)

In general, a patch consists of the following components:

Patch information:

Identification, which is the patch version and patch ID

Applicability, which is the operating system type, operating
system version, and architecture

Dependencies, such as requires and obsoletes

Properties, such as requires a reboot afterwards

One or more packages to patch, where each package contains:

The version of the package to which the patches can be applied

Patch information, such as ID, obsoletes, and requires

One or more components of the package to be patched

When the patchadd command is used to apply a patch,
the patch information is used to determine whether the patch is applicable
to the currently running system. If determined to be not applicable, the patch
is not applied. Patch dependencies are also checked against all of the zones
on the system. If any required dependencies are not met, the patch is not
applied. This could include the case in which a later version of the patch
is already installed.

Each package contained in the patch is checked. If the package is not
installed on any zone, then the package is bypassed and not patched.

If all dependencies are satisfied, all packages in the patch that are
installed on any zone are used to patch the system. The package and patch
databases are also updated.

Applying Patches on a Solaris System With
Zones Installed (SVr4
Only)

All patches applied at the global zone level are applied across all
zones. When a non-global zone is installed, it is at the same patch level
as the global zone. When the global zone is patched, all non-global zones
are similarly patched. This action maintains the same patch level across all
zones.

The patchadd system utility described in the patchadd(1M) man page
is used to add patches on a system with zones installed.

Using patchadd in the
Global Zone

To add a patch to the global zone and to all non-global zones, run patchadd as the global administrator in the global zone.

When patchadd is used in the global zone, the following
conditions apply:

The patchadd utility is able to add the
patch(es) to the global zone and to all non-global zones only. This is the
default action.

The patchadd utility cannot add the patch(es)
to the global zone only or to a subset of the non-global zones.

When you add a patch to the global zone and to all non-global zones,
you do not have to consider whether the patch affects areas that are shared
from the global zone.

The following steps are performed by the patchadd utility:

The patch is added to the global zone.

The patch database on the global zone is updated.

The patch is added to each non-global zone.

The patch database on each non-global zone is updated.

Using patchadd in a
Non-Global Zone

When used in a non-global zone by the zone administrator, patchadd can only be used to add patches to that zone. A patch can be added
to a non-global zone in the following cases:

The patch does not affect any area of the zone that is shared
from the global zone.

All packages in the patch are set SUNW_PKG_ALLZONES=false.

The following steps are performed by the patchadd utility:

The patch is added to the zone.

The patch database on the zone is updated.

Interaction of patchadd -G and the pkginfo Variable on a System With Zones

The following list specifies the interaction between the -G option
and the SUNW_PKG_ALLZONES variable when adding a patch
in global and non-global zones.

Global zone, -G specified

If any packages have SUNW_PKG_ALLZONES=TRUE,
this use results in an error and no action.

If no packages have SUNW_PKG_ALLZONES=TRUE, patch
is applied to package(s) in global zone only.

Global zone, -G not specified

If any packages have SUNW_PKG_ALLZONES=TRUE,
patch is applied to those package(s) in all zones.

If any packages do not have SUNW_PKG_ALLZONES=TRUE,
patch is applied to those package(s) in all appropriate zones. Global zone
only packages are installed only in the global zone.

Non-global zone, -G specified or not specified

If any packages have SUNW_PKG_ALLZONES=TRUE,
this use results in an error and no action.

If no packages have SUNW_PKG_ALLZONES=TRUE, patch
is applied to packages in non-global zone only.

Removing Patches on a Solaris System With
Zones Installed (SVR4
Only)

The patchrm system utility described in the patchrm(1M) man page
is used to remove patches on a system with zones installed.

Using patchrm in the
Global Zone

As the global administrator, you can use the patchrm utility
in the global zone to remove patches. The patchrm utility
cannot remove patches from the global zone only or from a subset of the non-global
zones.

Using patchrm in a Non-Global
Zone

As the zone administrator, you can use the patchrm utility
in a non-global zone to remove patches from that non-global zone only. Patches
cannot affect areas that are shared.

PatchPro Support (SVr4 Only)

PatchPro can be used in the global zone and in any non-global
zone. If run in the global zone, PatchPro uses the existing patch database
and patch tools to patch the global and all non-global zones for all software
that is installed on the global zone. No software installed in a non-global
zone that is not also installed in the global zone will be taken into account.

A zone administrator can run PatchPro in a non-global zone to patch
the software installed in the non-global zone.

Product Database (SVr4 Only)

Each zone's respective package, patch, and product registry database
completely describes all installed software that is available on the zone.
All dependency checking for installing additional software or patches is performed
without accessing any other zone's database, unless a package or patch is
being installed or removed on the global zone and on one or more non-global
zones. In this case, the appropriate non-global zone database(s) must be accessed.

Chapter 25 Adding and Removing Packages and Patches
on a Solaris System With Zones Installed (Tasks)

This chapter describes how to add and remove packages and patches on
a system using SVR4 packaging with zones installed. Other tasks associated with managing packages
and patches, such as checking package parameter settings and obtaining package
information, are also addressed. For an overview of patching and packaging
concepts on a system using
SVR4 packaging with zones installed, see Chapter 24, About Packages and Patches on a Solaris System With Zones Installed (Overview).

How to Remove a Patch From a Specified
Non-Global Zone Only

To remove a patch from a specified non-global zone only, the SUNW_PKG_ALLZONES package parameter for all packages in the patch set must be set
to false.

You must be the zone administrator in the non-global zone to perform
this procedure.

Log in to the non-global zone as the zone administrator.

While in the non-global zone, my-zone in this procedure, execute the patchrm command
followed by the patch ID.

my-zone# patchrm patch_id

Checking Package Parameter Settings on
a System with Zones Installed

Before you add or remove a software package, you can use the pkgparam command to check package parameter settings. This step is optional.
This check also can be done when troubleshooting why a package is not added
or removed as expected. For information about displaying package parameter
values, see the pkgparam(1) man
page.

(Optional) How to Check the Setting of
a Package Already Installed on the System

To check the package parameter setting of a package that is already
installed in a global or non-global zone, use pkgparam followed
by the package name and the name of the parameter.

Global Zone Visibility and Access

The global zone acts as both the default zone for the system and as
a zone for system-wide administrative control. There are administrative issues
associated with this dual role. Since applications within the zone have access
to processes and other system objects in other zones, the effect of administrative
actions can be wider than expected. For example, service shutdown scripts
often use pkill to signal processes of a given name to
exit. When such a script is run from the global zone, all such processes in
the system will be signaled, regardless of zone.

The system-wide scope is often needed. For example, to monitor system-wide
resource usage, you must view process statistics for the whole system. A view
of just global zone activity would miss relevant information from other zones
in the system that might be sharing some or all of the system resources. Such
a view is particularly important when system resources such as CPU are not
strictly partitioned using resource management facilities.

Thus, processes in the global zone can observe processes and other objects
in non-global zones. This allows such processes to have system-wide observability.
The ability to control or send signals to processes in other zones is restricted
by the privilege PRIV_PROC_ZONE. The privilege is similar
to PRIV_PROC_OWNER because the privilege allows processes
to override the restrictions placed on unprivileged processes. In this case,
the restriction is that unprivileged processes in the global zone cannot signal
or control processes in other zones. This is true even when the user IDs of
the processes match or the acting process has the PRIV_PROC_OWNER privilege.
The PRIV_PROC_ZONE privilege can be removed from otherwise
privileged processes to restrict actions to the global zone.

For information about matching processes by using a zoneidlist,
see the pgrep(1)pkill(1) man pages.

Process ID Visibility in Zones

Only processes in the same zone will be visible through system call
interfaces that take process IDs, such as the kill and priocntl commands. For information, see the kill(1) and the priocntl(1) man pages.

System Observability in Zones

The ps command has the following modifications:

The -o option is used to specify output format.
This option allows you to print the zone ID of a process or the name of the
zone in which the process is running.

The -zzonelist option
is used to list only processes in the specified zones. Zones can be specified
either by zone name or by zone ID. This option is only useful when the command
is executed in the global zone.

The -Z option is used to print the name of
the zone associated with the process. The name is printed under the column
heading ZONE.

Non-Global Zone Node Name

The node name
in /etc/nodename returned by uname-n can be set by the zone administrator. The node name must be unique.

File Systems and Non-Global Zones

This section provides information about file system issues on a Solaris
system with zones installed. Each zone has its own section of the file system
hierarchy, rooted at a directory known as the zone root.
Processes in the zone can access only files in the part of the hierarchy that
is located under the zone root. The chroot utility can
be used in a zone, but only to restrict the process to a root path within
the zone. For more information about chroot, see chroot(1M).

The -onosuid Option

The -onosuid option to the mount utility has the following functionality:

Processes from a setuid binary located
on a file system that is mounted using the nosetuid option
do not run with the privileges of the setuid binary. The
processes run with the privileges of the user that executes the binary.

For example, if a user executes a setuid binary that
is owned by root, the processes run with the privileges
of the user.

Opening device-special entries in the file system is not allowed.
This behavior is equivalent to specifying the nodevices option.

This file system-specific option is available to all Solaris file systems
that can be mounted with mount utilities, as described
in the mount(1M) man
page. In this guide, these file systems are listed in Mounting File Systems in Zones. Mounting
capabilities are also described. For more information about the -onosuid option, see “Accessing Network File Systems (Reference)”
in System Administration Guide: Network Services.

Mounting File Systems in Zones

When file systems are mounted from within a zone, the nodevices option
applies. For example, if a zone is granted access to a block device (/dev/dsk/c0t0d0s7) and a raw device (/dev/rdsk/c0t0d0s7) corresponding
to a UFS file system, the file system is automatically mounted nodevices when mounted from within a zone. This rule does not apply to mounts
specified through a zonecfg configuration.

Unmounting File Systems in Zones

The ability to unmount a file system will depend on who performed the
initial mount. If a file system is specified as part of the zone's configuration
using the zonecfg command, then the global zone owns this
mount and the non-global zone administrator cannot unmount the file system.
If the file system is mounted from within the non-global zone, for example,
by specifying the mount in the zone's /etc/vfstab file,
then the non-global zone administrator can unmount the file system.

Security Restrictions and File System Behavior

There are security restrictions on mounting certain file systems from
within a zone. Other file systems exhibit special behavior when mounted in
a zone. The list of modified file systems follows.

AutoFS

Autofs is a client-side service that automatically mounts
the appropriate file system. When a client attempts to access a file system
that is not presently mounted, the AutoFS file system intercepts the request
and calls automountd to mount the requested directory.
AutoFS mounts established within a zone are local to that zone. The mounts
cannot be accessed from other zones, including the global zone. The mounts
are removed when the zone is halted or rebooted. For more information on AutoFS,
see How Autofs Works in System Administration Guide: Network Services.

Each zone runs its own copy of automountd. The auto
maps and timeouts are controlled by the zone administrator. You cannot trigger
a mount in another zone by crossing an AutoFS mount point for a non-global
zone from the global zone.

Certain AutoFS mounts are created in the kernel when another mount is
triggered. Such mounts cannot be removed by using the regular umount interface
because they must be mounted or unmounted as a group. Note that this functionality
is provided for zone shutdown.

MNTFS

MNTFS is a virtual file system that provides read-only access
to the table of mounted file systems for the local system. The set of file
systems visible by using mnttab from within a non-global
zone is the set of file systems mounted in the zone, plus an entry for root
(/) . Mount points with a special device that is not accessible
from within the zone, such as /dev/rdsk/c0t0d0s0, have
their special device set to the same as the mount point. All mounts in the
system are visible from the global zone's /etc/mnttab table.
For more information on MNTFS, see Chapter 19, Mounting and Unmounting File Systems (Tasks), in System Administration Guide: Devices and File Systems.

NFS

NFS mounts established within a zone are local to that zone.
The mounts cannot be accessed from other zones, including the global zone.
The mounts are removed when the zone is halted or rebooted.

As documented in the mount_nfs(1M) man page, an NFS server should
not attempt to mount its own file systems. Thus, a zone should not NFS mount
a file system exported by the global zone. Zones cannot be NFS servers. From
within a zone, NFS mounts behave as though mounted with the nodevices option.

The nfsstat command output only pertains to the zone
in which the command is run. For example, if the command is run in the global
zone, only information about the global zone is reported. For more information
about the nfsstat command, see nfsstat(1M).

The zlogin command will fail if any of its open files
or any portion of its address space reside on NFS. For more information, see zlogin Command.

PROCFS

The /proc file system, or PROCFS, provides
process visibility and access restrictions as well as information about the
zone association of processes. Only processes in the same zone are visible
through /proc.

Processes in the global zone can observe processes and other objects
in non-global zones. This allows such processes to have system-wide observability.

From within a zone, procfs mounts behave as though
mounted with the nodevices option. For more information
about procfs, see the proc(4) man page.

LOFS

The scope of what can be mounted through LOFS is limited to
the portion of the file system that is visible to the zone. Hence, there are
no restrictions on LOFS mounts in a zone.

UFS, UDFS, PCFS, and other storage-based file systems

When using the zonecfg command to configure
storage-based file systems that have an fsck binary, such
as UFS, the zone administrator must specify a raw parameter.
The parameter indicates the raw (character) device, such as /dev/rdsk/c0t0d0s7. zoneadmd automatically runs the fsck command
in non-interactive check-only mode (fsck-m)
on this device before it mounts the file system. If the fsck fails, zoneadmd cannot bring the zone to the ready state. The path specified
by raw cannot be a relative path.

It is an error to specify a device to fsck for a
file system that does not provide an fsck binary in /usr/lib/fs/fstype/fsck. It is
also an error if you do not specify a device to fsck if
an fsck binary exists for that file system.

You can add a ZFS dataset to a non-global zone by using the zonecfg command with the add dataset resource.
The dataset will be visible and mounted in the non-global zone and no longer
visible in the global zone. The zone administrator can create and destroy
file systems within that dataset, and modify the properties of the dataset.

The zoned attribute of zfs indicates
whether a dataset has been added to a non-global zone.

# zfs get zoned tank/sales
NAME PROPERTY VALUE SOURCE
tank/sales zoned on local

If you want to share a dataset from the global zone, you can add an
LOFS-mounted ZFS file system by using the zonecfg command
with the addfs subcommand. The global
administrator is responsible for setting and controlling the properties of
the dataset.

Use of mknod Prohibited
in a Zone

Note that you cannot use the mknod command documented
in the mknod(1M) man page to make a special file in a non-global zone.

Traversing File Systems

A zone's file system namespace is a subset of the namespace accessible
from the global zone. Unprivileged processes in the global zone are prevented
from traversing a non-global zone's file system hierarchy through the following
means:

Specifying that the zone root's parent directory is owned,
readable, writable, and executable by root only

Restricting access to directories exported by /proc

Note that attempting to access AutoFS nodes mounted for another zone
will fail. The global administrator must not have auto maps that descend into
other zones.

Restriction on Accessing A Non-Global Zone
From the Global Zone

After a non-global zone is installed, the zone must never be accessed
directly from the global zone by any commands other than system backup utilities.
Moreover, a non-global zone can no longer be considered secure after it has
been exposed to an unknown environment. An example would be a zone placed
on a publicly accessible network, where it would be possible for the zone
to be compromised and the contents of its file systems altered. If there is
any possibility that compromise has occurred, the global administrator should
treat the zone as untrusted.

Any command that accepts an alternative root by using the -R or -b options (or the equivalent) must not be used
when the following are true:

The command is run in the global zone.

The alternative root refers to any path within a non-global
zone, whether the path is relative to the current running system's global
zone or the global zone in an alternative root.

An example is the -Rroot_path option
to the pkgadd utility run from the global zone with a non-global
zone root path.

The list of commands, programs, and utilities that use -R with
an alternative root path include the following:

auditreduce

bart

flar

flarcreate

installf

localeadm

makeuuid

metaroot

patchadd

patchrm

pkgadd

pkgadm

pkgask

pkgchk

pkgrm

prodreg

removef

routeadm

showrev

syseventadm

The list of commands and programs that use -b with an
alternative root path include the following:

add_drv

pprosetup

rem_drv

roleadd

sysidconfig

update_drv

useradd

Networking in Shared-IP Non-Global Zones

On
a Solaris system with zones installed, the zones can communicate with each
other over the network. The zones all have separate bindings, or connections,
and the zones can all run their own server daemons. These daemons can listen
on the same port numbers without any conflict. The IP stack resolves conflicts
by considering the IP addresses for incoming connections. The IP addresses
identify the zone.

Shared-IP Zone Partitioning

The IP stack in a system supporting zones implements the separation
of network traffic between zones. Applications that receive IP traffic can
only receive traffic sent to the same zone.

Each logical interface on the system belongs to a specific zone, the
global zone by default. Logical network interfaces assigned to zones though
the zonecfg utility are used to communicate over the network.
Each stream and connection belongs to the zone of the process that opened
it.

Bindings between upper-layer streams and logical interfaces are restricted.
A stream can only establish bindings to logical interfaces in the same zone.
Likewise, packets from a logical interface can only be passed to upper-layer
streams in the same zone as the logical interface.

Each zone has its own set of binds. Each zone can be running the same
application listening on the same port number without binds failing because
the address is already in use. Each zone can run its own version of the following
services:

Internet services daemon with a full configuration file (see
the inetd(1M) man
page)

Zones other than the global zone have restricted access to the network.
The standard TCP and UDP socket interfaces are available, but SOCK_RAW socket
interfaces are restricted to Internet Control Message Protocol (ICMP). ICMP
is necessary for detecting and reporting network error conditions or using
the ping command.

Shared-IP Network Interfaces

Each non-global zone that requires network connectivity has one or more
dedicated IP addresses. These addresses are associated with logical network
interfaces that can be placed in a zone by using the ifconfig command.
Zone network interfaces configured by zonecfg will automatically
be set up and placed in the zone when it is booted. The ifconfig command
can be used to add or remove logical interfaces when the zone is running.
Only the global administrator can modify the interface configuration and the
network routes.

Within a non-global zone, only that zone's interfaces will be visible
to ifconfig.

IP Traffic Between Shared-IP Zones on the
Same Machine

Between two zones on the same machine, packet delivery is only allowed
if there is a “matching route” for the destination and the zone
in the forwarding table.

The matching information is implemented as follows:

The source address for the packets is selected on the output
interface specified by the matching route.

By default, traffic is permitted between two zones that have
addresses on the same subnet. The matching route in this case is the interface
route for the subnet.

If there is a default route for a given zone, where the gateway
is on one of the zone's subnets, traffic from that zone to all other zones
is allowed. The matching route in this case is the default route.

If there is a matching route with the RTF_REJECT flag,
packets trigger an ICMP unreachable message. If there is a matching route
with the RTF_BLACKHOLE flag, packets are discarded. The
global administrator can use the route command options
described in the following table to create routes with these flags.

Solaris IP Filter in Shared-IP Zones

Solaris IP Filter provides stateful packet filtering and network address
translation (NAT). A stateful packet filter can monitor the state of active
connections and use the information obtained to determine which network packets
to allow through the firewall. Solaris IP Filter also includes stateless packet
filtering and the ability to create and manage address pools. See Chapter 25, Solaris IP Filter (Overview), in System Administration Guide: IP Services for additional information.

IP Network Multipathing in Shared-IP Zones

IP network multipathing (IPMP) provides physical interface failure detection
and transparent network access failover for a system with multiple interfaces
on the same IP link. IPMP also provides load spreading of packets for systems
with multiple interfaces.

All network configuration is done in the global zone. You can configure
IPMP in the global zone, then extend the functionality to non-global zones.
The functionality is extended by placing the zone's 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 will migrate to another network
interface card.

In a given non-global zone, only the interfaces associated with the
zone are visible through the ifconfig command.

Exclusive-IP Zone Partitioning

Exclusive-IP zones have separate TCP/IP stacks, so the separation reaches
down to the data-link layer. One or more data-link names, which can be a NIC
or a VLAN on a NIC, are assigned to an exclusive-IP zone by the global administrator.
The zone administrator can configure IP on those data-links with the same
flexibility and options as in the global zone.

Exclusive-IP Data-Link Interfaces

A data-link name must be assigned exclusively to a single zone.

The dladmshow-link command can
be used to display data-links assigned to running zones.

IP Traffic Between Exclusive-IP Zones on the Same
Machine

There is no internal loopback of IP packets between exclusive-IP zones.
All packets are sent down to the data-link. Typically, this means that the
packets are sent out on a network interface. Then, devices like Ethernet switches
or IP routers can forward the packets toward their destination, which might
be a different zone on the same machine as the sender.

Solaris IP Filter in Exclusive-IP Zones

You have the same IP Filter functionality that you have in the global
zone in an exclusive-IP zone. IP Filter is also configured the same way in
exclusive-IP zones and the global zone.

IP Network Multipathing in Exclusive-IP Zones

IP network multipathing (IPMP) provides physical interface failure detection
and transparent network access failover for a system with multiple interfaces
on the same IP link. IPMP also provides load spreading of packets for systems
with multiple interfaces.

The data-link configuration is done in the global zone. First, multiple
data-link interfaces are assigned to a zone using zonecfg.
The multiple data-link interfaces must be attached to the same IP subnet.
IPMP can then be configured from within the exclusive-IP zone by the zone
administrator.

Device Use in Non-Global Zones

The set of devices available within a zone is restricted to prevent
a process in one zone from interfering with processes running in other zones.
For example, a process in a zone cannot modify kernel memory or modify the
contents of the root disk. Thus, by default, only certain pseudo-devices
that are considered safe for use in a zone are available. Additional devices
can be made available within specific zones by using the zonecfg utility.

/dev and the /devices Namespace

The devfs file system described in the devfs(7FS) man page
is used by the Solaris system to manage /devices. Each
element in this namespace represents the physical path to a hardware device,
pseudo-device, or nexus device. The namespace is a reflection of the device
tree. As such, the file system is populated by a hierarchy of directories
and device special files.

Devices are grouped according to the relative /dev hierarchy.
For example, all of the devices under /dev in the global
zone are grouped as global zone devices. For a non-global zone, the devices
are grouped in a /dev directory under the zone's root path.
Each group is a mounted /dev file system instance that
is mounted under the /dev directory. Thus, the global zone
devices are mounted under /dev, while the devices for a
non-global zone named my-zone are mounted under /my-zone_rootpath/dev.

The /dev file hierarchy is managed by the dev file system described in the dev(7FS) man page.

Caution –

Subsystems that rely on /devices path
names are not able to run in non-global zones. The subsystems must be updated
to use /dev path names.

Exclusive-Use Devices

You might have devices that you want to assign to specific zones. Allowing
unprivileged users to access block devices could permit those devices to be
used to cause system panic, bus resets, or other adverse effects. Before making
such assignments, consider the following issues:

Before assigning a SCSI tape device to a specific zone, consult
the sgen(7D) man
page.

Placing a physical device into more than one zone can create
a covert channel between zones. Global zone applications that use such a device
risk the possibility of compromised data or data corruption by a non-global
zone.

Device Driver Administration

In a non-global zone, you can use the modinfo command
described in the modinfo(1M) man
page to examine the list of loaded kernel modules.

Most operations concerning kernel, device, and platform management will
not work inside a non-global zone because modifying platform hardware configurations
violates the zone security model. These operations include the following:

Adding and removing drivers

Explicitly loading and unloading kernel modules

Initiating dynamic reconfiguration (DR) operations

Using facilities that affect the state of the physical platform

Utilities That Do Not Work or Are Modified
in Non-Global Zones

Utilities That Do Not Work in Non-Global
Zones

The following utilities do not work in a zone because they rely on devices
that are not normally available:

SPARC: Utility Modified for Use in
a Non-Global Zone

The eeprom utility can be used in a zone to view
settings. The utility cannot be used to change settings. For more information,
see the eeprom(1M) and openprom(7D) man pages.

Running Applications in Non-Global Zones

In general, all applications can run in a non-global zone. However,
the following types of applications might not be suitable for this environment:

Applications that use privileged operations that affect the
system as a whole. Examples include operations that set the global system
clock or lock down physical memory.

The few applications dependent upon certain devices that do
not exist in a non-global zone, such as /dev/kmem.

Applications that expect to be able to write into /usr,
either at runtime or when being installed, patched, or upgraded. This is because /usr is read-only for a non-global zone by default. Sometimes the
issues associated with this type of application can be mitigated without changing
the application itself.

In a shared-IP zone, applications dependent upon devices in /dev/ip.

Resource Controls Used in Non-Global Zones

For additional information about using a resource management feature
in a zone, also refer to the chapter that describes the feature in Part 1
of this guide.

Any of the resource controls and attributes described in the resource
management chapters can be set in the global and non-global zone /etc/project file, NIS map, or LDAP directory service. The settings for a given
zone affect only that zone. A project running autonomously in different zones
can have controls set individually in each zone. For example, Project A in
the global zone can be set project.cpu-shares=10 while
Project A in a non-global zone can be set project.cpu-shares=5.
You could have several instances of rcapd running on the
system, with each instance operating only on its zone.

The resource controls and attributes used in a zone to control projects,
tasks, and processes within that zone are subject to the additional requirements
regarding pools and the zone-wide resource controls.

A “one zone, one pool” rule applies to non-global zones.
Multiple non-global zones can share the resources of one pool. Processes in
the global zone, however, can be bound by a sufficiently privileged process
to any pool. 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.

Zone-wide resource controls do not take effect when they are set in
the project file. A zone-wide resource control is set
through the zonecfg utility.

Fair Share Scheduler on a Solaris System
With Zones Installed

This section describes how to use the fair share scheduler (FSS) with
zones.

FSS Share Division in a Global or Non-Global
Zone

FSS CPU shares for a zone are hierarchical. The shares for the global
and non-global zones are set by the global administrator through the zone-wide
resource control zone.cpu-shares. The project.cpu-shares resource control can then be defined for each project within that
zone to further subdivide the shares set through the zone-wide control.

Share Balance Between Zones

You can use zone.cpu-shares to assign FSS shares
in the global zone and in non-global zones. If FSS is the default scheduler
on your system and shares are not assigned, each zone is given one share by
default. If you have one non-global zone on your system and you give this
zone two shares through zone.cpu-shares, that defines the
proportion of CPU which the non-global zone will receive in relation to the
global zone. The ratio of CPU between the two zones is 2:1.

Extended Accounting on a Solaris System With
Zones Installed

The extended accounting subsystem collects and reports information for
the entire system (including non-global zones) when run in the global zone.
The global administrator can also determine resource consumption on a per-zone
basis.

The extended accounting subsystem permits different accounting settings
and files on a per-zone basis for process-based and task-based accounting.
The exacct records can be tagged with the zone name EXD
PROC ZONENAME for processes, and the zone name EXD TASK
ZONENAME for tasks. Accounting records are written to the global
zone's accounting files as well as the per-zone accounting files. The EXD
TASK HOSTNAME, EXD PROC HOSTNAME, and EXD
HOSTNAME records contain the uname-n value
for the zone in which the process or task executed instead of the global zone's
node name.

Privileges in a Non-Global Zone

Processes
are restricted to a subset of privileges. Privilege restriction prevents a
zone from performing operations that might affect other zones. The set of
privileges limits the capabilities of privileged users within the zone. To
display the list of privileges available from within a given zone, use the ppriv utility.

The following table lists all of the Solaris privileges and the status
of each privilege with respect to zones. Optional privileges are not part
of the default set of privileges but can be specified through the limitpriv property. Required privileges must be included in the resulting
privilege set. Prohibited privileges cannot be included in the resulting privilege
set.

If this privilege is assigned to a non-global zone by the system administrator,
consider also setting the zone.max-locked-memory resource
control to prevent the zone from locking all memory.

proc_owner

Default

Process control regardless of owner

proc_session

Default

Process control regardless of session

proc_setid

Default

Setting of user/group IDs at will

proc_taskid

Default

Assigning of task IDs to caller

sys_acct

Default

Management of accounting

sys_admin

Default

Simple system administration tasks

sys_audit

Default

Management of auditing

sys_nfs

Default

NFS client support

sys_resource

Default

Resource limit manipulation

The following table lists all of the Solaris Trusted Extensions privileges
and the status of each privilege with respect to zones. Optional privileges
are not part of the default set of privileges but can be specified through
the limitpriv property.

Note –

Trusted Solaris privileges are interpreted only if the system
is configured with Trusted Extensions.

Table 26–2 Status of Solaris Trusted Extensions
Privileges in Zones

Solaris Trusted Extensions Privilege

Status

Notes

file_downgrade_sl

Optional

Set the sensitivity label of file or directory to a sensitivity label
that does not dominate the existing sensitivity label

file_upgrade_sl

Optional

Set the sensitivity label of file or directory to a sensitivity
label that dominates the existing sensitivity label

sys_trans_label

Optional

Translate labels not dominated by sensitivity label

win_colormap

Optional

Colormap restrictions override

win_config

Optional

Configure or destroy resources that are permanently retained by the
X server

IP Security Architecture in Shared-IP Zones

IPsec can be used in the global zone. However, IPsec in a non-global
zone cannot use IKE. Therefore, you must manage the IPsec keys and policy
for the non-global zones by using the Internet
Key Exchange (IKE) protocol in the global zone. Use the source address
that corresponds to the non-global zone that you are configuring.

An audit record describes an event, such as logging in to a system or
writing to a file. The record is composed of tokens, which are sets of audit
data. By using the zonename token, you can configure Solaris
auditing to identify audit events by zone. Use of the zonename token
allows you to produce the following information:

Audit records that are marked with the name of the zone that
generated the record

An audit log for a specific zone that the global administrator
can make available to the zone administrator

Configuring Audit in the Global Zone

Solaris audit trails are configured in the global zone. Audit policy
is set in the global zone and applies to processes in all zones. The audit
records can be marked with the name of the zone in which the event occurred.
To include zone names in audit records, you must edit the /etc/security/audit_startup file before you install any non-global zones. The zone name selection
is case-sensitive.

To configure auditing in the global zone to include all zone audit records,
add this line to the /etc/security/audit_startup file:

/usr/sbin/auditconfig -setpolicy +zonename

As the global administrator in the global zone, execute the auditconfig utility:

global# auditconfig -setpolicy +zonename

For additional information, see the audit_startup(1M) and auditconfig(1M) man pages and “Configuring Audit Files (Task
Map)” in System Administration Guide: Security Services.

Configuring User Audit Characteristics in
a Non-Global Zone

When a non-global zone is installed, the audit_control file
and the audit_user file in the global zone are copied to
the zone's /etc/security directory. These files might
require modification to reflect the zone's audit needs.

For example, each zone can be configured to audit some users differently
from others. To apply different per-user preselection criteria, both the audit_control and the audit_user files must
be edited. The audit_user file in the non-global zone might
also require revisions to reflect the user base for the zone if necessary.
Because each zone can be configured differently with regard to auditing users,
it is possible for the audit_user file to be empty.

Providing Audit Records for a Specific Non-Global
Zone

By including the zonename token as described in Configuring Audit in the Global Zone, Solaris
audit records can be categorized by zone. Records from different zones can
then be collected by using the auditreduce command to create
logs for a specific zone.

Core Files in Zones

The coreadm command is used to specify the name and
location of core files produced by abnormally terminating processes. Core
file paths that include the zonename of the zone
in which the process executed can be produced by specifying the %z variable.
The path name is relative to a zone's root directory.

Running DTrace in a Non-Global Zone

DTrace programs
that only require the dtrace_proc and dtrace_user privileges
can be run in a non-global zone. To add these privileges to the set of privileges
available in the non-global zone, use the zonecfglimitpriv property. For instructions, see How to Use DTrace.

The providers supported through dtrace_proc are fasttrap and pid. The providers supported through dtrace_user are profile and syscall.
DTrace providers and actions are limited in scope to the zone.

About Backing Up a Solaris System With Zones Installed

You can perform backups in individual non-global zones, or back up the
entire system from the global zone.

Backing Up Loopback File System Directories

Because many non-global zones share files with the global zone through
the use of loopback file system read-only mounts (usually /usr, /lib, /sbin, and /platform),
you must use a global zone backup method to back up lofs directories.

Caution –

Do not back up the lofs file systems in
non-global zones. An attempt by the non-global administrator to restore lofs file systems from a non-global zone could cause a serious problem.

Backing Up Your System From the Global Zone

You might choose to perform your backups from the global zone in the
following cases:

You want to back up the configurations of your non-global
zones as well as the application data.

Your primary concern is the ability to recover from a disaster.
If you need to restore everything or almost everything on your system, including
the root file systems of your zones and their configuration data as well as
the data in your global zone, backups should take place in the global zone.

You want to use the ufsdump command to
perform a data backup. Because importing a physical disk device into a non-global
zone would change the security profile of the zone, ufsdump should
only be used from the global zone.

You have commercial network backup software.

Note –

Your network backup software should be configured to skip all
inherited lofs file systems if possible. The backup should
be performed when the zone and its applications have quiesced the data to
be backed up.

Backing Up Individual Non-Global Zones on Your System

You might decide to perform backups within the non-global zones in the
following cases.

The non-global zone administrator needs the ability to recover
from less serious failures or to restore application or user data specific
to a zone.

You want to use programs that back up on a file-by-file basis,
such as tar or cpio. See the tar(1) and cpio(1) man pages.

You use the backup software of a particular application or
service running in a zone. It might be difficult to execute the backup software
from the global zone because application environments, such as directory path
and installed software, would be different between the global zone and the
non-global zone.

If the application can perform a snapshot on
its own backup schedule in each non-global zone and store those backups in
a writable directory exported from the global zone, the global zone administrator
can pick up those individual backups as part of the backup strategy from the
global zone.

Determining What to Back Up in Non-Global Zones

You can back up everything in the non-global zone, or, because a zone's
configuration changes less frequently, you can perform backups of the application
data only.

Backing Up Application Data Only

If application data is kept in a particular part of the file system,
you might decide to perform regular backups of this data only. The zone's
root file system might not have to be backed up as often because it changes
less frequently.

You will have to determine where the application places its files. Locations
where files can be stored include the following:

Users' home directories

/etc for configuration data files

/var

Assuming the application administrator knows where the data is stored,
it might be possible to create a system in which a per-zone writable directory
is made available to each zone. Each zone can then store its own backups,
and the global administrator can make this location one of the places on the
system to back up.

General Database Backup Operations

If the database application data is not under its own directory, the
following rules apply:

Ensure that the databases are in a consistent state first.

Databases must be quiesced because they have internal buffers to flush
to disk. Make sure that the databases in non-global zones have come down before
starting the backup from the global zone.

Within each zone, use file system features to make a snapshot
of the data, then back up the snapshots directly from the global zone.

This process will minimize elapsed time for the backup window and remove
the need for backup clients/modules in all of the zones.

Tape Backups

Each non-global zone can take a snapshot of its private file systems
when it is convenient for that zone and the application has been briefly quiesced.
Later, the global zone can back up each of the snapshots and put them on tape
after the application is back in service.

This method has the following advantages:

Fewer tape devices are needed.

There is no need for coordination between the non-global zones.

There is no need to assign devices directly to zones, which
improves security.

Generally, this method keeps system management in the global
zone, which is preferred.

About Restoring Non-Global Zones

In the case of a restore where the backups were done from the global
zone, the global administrator can reinstall the affected zones and then restore
that zone's files. Note that this assumes the following:

The zone being restored has the same configuration as it did
when the backup was done.

The global zone has not been upgraded or patched between the
time when the backup was done and the time when the zone is restored.

Otherwise, the restore could overwrite some files that should be merged
by hand.

For example, you might need to merge files by hand if a global zone
has been patched after the backup, but prior to the restore of the non-global
zone. In this case, you would have to be careful when restoring a zone's
files that were backed up since a backed up file might not be compatible with
the newly installed zone that was built after the patches were applied to
the global zone. In this case, you would have to examine the files individually
and compare them to the copies in the newly installed zone. In most cases,
you will find that the file can be copied directly in, but in some cases,
you must merge the changes originally made to the file into the newly installed
or patched copy in the zone.

Note –

If all file systems in the global zone are lost, restoring everything
in the global zone restores the non-global zones as well, as long as the respective
root file systems of the non-global zones were included in the backup.

Commands Used on a Solaris System With Zones
Installed

The commands
identified in Table 26–3 provide
the primary administrative interface to the zones facility.

The commands identified in the following table have been modified for
use on a Solaris system with zones installed. These commands have options
that are specific to zones or present information differently. The commands
are listed by man page section.

Table 26–5 Commands Modified for Use
on a Solaris System With Zones Installed

If executed in a non-global zone in which the pools facility is enabled,
the -b, -c-g, -m, -p, -u, -w, and -y options
display values only for processors that are in the processor set of the pool
to which the zone is bound.

If executed in a non-global zone in which the pools facility is enabled,
the percentage of recent CPU time used by the process is displayed only for
the processors in the processor set of the pool to which the zone is bound.

Output of the -a, -t, -T, -J, and -Z options displays a SWAP instead of a SIZE
column. The swap reported is the total swap consumed by the zone's processes
and tmpfs mounts. This value assists in monitoring the
swap reserved by each zone, which can be used to choose a reasonable zone.max-swap setting.

When executed in a non-global zone in which the pools facility is enabled,
statistics are reported only for the processors in the processor set of the
pool to which the zone is bound. Applies to output from the -p option
and the page, faults, and cpu report
fields.

If the caller is in a non-global zone and the pools facility enabled, sysconf(_SC_NPROCESSORS_CONF) and sysconf(_SC_NPROCESSORS_ONLN) return the number of total and online processors in the processor
set of the pool to which the zone is bound.

Using the ppriv Utility

How to List Solaris Privileges in the Global Zone

Use the ppriv utility with the -l option
to list the privileges available on the system.

At the prompt, type ppriv-lzone to report the set of privileges available in the zone.

global# ppriv -l zone

You will see a display similar to this:

contract_event
contract_observer
cpc_cpu
.
.
.

How to List the Non-Global Zone's Privilege
Set

Use the ppriv utility with the -l option
and the expression zone to list the zone's privileges.

Log into the non-global zone. This example
uses a zone named my-zone.

At the prompt, type ppriv-lzone to report the set of privileges available
in the zone.

my-zone# ppriv -l zone

You will see a display similar to this:

contract_event
contract_observer
file_chown
.
.
.

How to List a Non-Global Zone's Privilege
Set With Verbose Output

Use the ppriv utility with the -l option,
the expression zone, and the -v option
to list the zone's privileges.

Log into the non-global zone. This example
uses a zone named my-zone.

At the prompt, type ppriv-l-vzone to report the set of
privileges available in the zone, with a description of each privilege.

my-zone# ppriv -lv zone

You will see a display similar to this:

contract_event
Allows a process to request critical events without limitation.
Allows a process to request reliable delivery of all events on
any event queue.
contract_observer
Allows a process to observe contract events generated by
contracts created and owned by users other than the process's
effective user ID.
Allows a process to open contract event endpoints belonging to
contracts created and owned by users other than the process's
effective user ID.
file_chown
Allows a process to change a file's owner user ID.
Allows a process to change a file's group ID to one other than
the process' effective group ID or one of the process'
supplemental group IDs.
.
.
.

See Also

Mounting File Systems in Running Non-Global
Zones

You can mount file systems in a running non-global zone. The following
procedures are covered.

As the global administrator in the global zone, you can import
raw and block devices into a non-global zone. After the devices are imported,
the zone administrator has access to the disk. The zone administrator can
then create a new file system on the disk and perform one of the following
actions:

Mount the file system manually

Place the file system in /etc/vfstab so
that it will be mounted on zone boot

As the global administrator, you can also mount a file system
from the global zone into the non-global zone.

SX Only: How to Import Raw and Block Devices
by Using zonecfg

This procedure uses the lofi file driver, which exports
a file as a block device.

See Also

How to Add Access to CD or DVD Media in a Non-Global
Zone

This procedure enables you to add read-only access to CD or DVD media
in a non-global zone. The Volume Management file system is used in the global
zone for mounting the media. A CD or DVD can then be used to install a product
in the non-global zone. This procedure uses a DVD named jes_05q4_dvd.

Using IP Network Multipathing on a Solaris
System With Zones Installed

How to Use IP Network Multipathing in Exclusive-IP
Non-Global Zones

IP Network Multipathing (IPMP) in an exclusive-IP zone is configured
as it is in the global zone.

You can configure one or more physical interfaces into an IP multipathing
group, or IPMP group. After configuring IPMP, the system automatically monitors
the interfaces in the IPMP group for failure. If an interface in the group
fails or is removed for maintenance, IPMP automatically migrates, or fails
over, the failed interface's IP addresses. The recipient of these addresses
is a functioning interface in the failed interface's IPMP group. The failover
feature of IPMP preserves connectivity and prevents disruption of any existing
connections. Additionally, IPMP improves overall network performance by automatically
spreading out network traffic across the set of interfaces in the IPMP group.
This process is called load spreading.

How to Set FSS Shares in the Global Zone
Using the prctl Command

The global zone is given one share by default. You can use this procedure
to change the default allocation. Note that you must reset shares allocated
through the prctl command whenever you reboot the system.

You must be the global administrator in the global zone to perform this
procedure.

Example—Using Profile Shells With
Zone Commands

You can execute zone commands in a profile using the pfexec program.
The program executes commands with the attributes specified by the user's
profiles in the exec_attr database. The program is invoked
by the profile shells pfksh, pfcsh,
and pfsh.

Use the pfexec program to log in to a zone, for example, my-zone.

machine$ pfexec zlogin my-zone

Backing Up a Solaris System With Installed Zones

The following procedures can be used to back up files in zones. Remember
to also back up the zones' configuration files.

How to Use ufsdump to Perform Backups

You can perform full or incremental backups using the ufsdump command.
This procedure backs up the zone /export/my-zone to /backup/my-zone.ufsdump, where my-zone is replaced with the
name of a zone on your system. You might want to have a separate file system,
for example, a file system mounted on /backup, to hold
the backups.

How to Create a UFS Snapshot Using fssnap

This approach uses the fssnap command, which creates
a temporary image of a file system intended for backup operations.

This method can be used to provide a clean, consistent backup of the
zone files only, and it can be executed while zones are running. However,
it is a good idea to suspend or checkpoint active applications that are updating
files when the snapshot is created. An application updating files when the
snapshot is created might leave these files in an internally inconsistent,
truncated, or otherwise unusable state.

In the example procedure below, note the following:

There is a zone named my-zone under /export/home.

/export/home is a separate file system.

Before You Begin

The destination backup is /backup/my-zone.ufs. You
must create the directory backup under /.

How to Print a Copy of a Zone Configuration

You should create backup files of your non-global zone configurations.
You can use the backups to recreate the zones later if necessary. Create the
copy of the zone's configuration after you have logged in to the zone for
the first time and have responded to the sysidtool questions.
This procedure uses a zone named my-zone and a backup file
named my-zone.config to illustrate the process.

Print the configuration for the zone my-zone to
a file named my-zone.config.

global# zonecfg -z my-zone export > my-zone.config

Restoring a Non-Global Zone

How to Restore an Individual Non-Global Zone

You can use the backup files of your non-global zone configurations
to restore non-global zones, if necessary. This procedure uses a zone named my-zone and a backup file named my-zone.config to
illustrate the process of restoring a zone.

Exclusive-IP Zone Is Using Device, so dladmreset-linkprop Fails

Referring to How to Use dladmreset-linkprop,
the attempt to use dladmreset-linkprop failed.
The running zone excl is using the device, which was assigned
by executing ifconfigbge0plumb inside
the zone.

To reset the value, use the procedure ifconfigbge0unplumb inside the zone and rerun the dladm command.

Incorrect Privilege Set Specified in Zone Configuration

If the zone's privilege set contains a disallowed privilege, is missing
a required privilege, or includes an unknown privilege name, an attempt to
verify, ready, or boot the zone will fail with an error message such as the
following:

The presence of files within a file system hierarchy when a non-global
zone is first booted indicates that the file system data is managed by the
global zone. When the non-global zone was installed, a number of the packaging
files in the global zone were duplicated inside the zone. These files must
reside under the zonepath directly. If the files reside
under a file system created by a zone administrator on disk devices or ZFS
datasets added to the zone, packaging and patching problems could occur.

The issue with storing any of the file system data that is managed by
the global zone in a zone-local file system can be described by using ZFS
as an example. If a ZFS dataset has been delegated to a non-global zone, the
zone administrator should not use that dataset to store any of the file system
data that is managed by the global zone. The configuration could not be patched
or upgraded correctly.

For example, a ZFS delegated dataset should not be used as a /var file
system. The Solaris operating system delivers core packages that install components
into /var. These packages have to access /var when
they are upgraded or patched, which is not possible if /var is
mounted on a delegated ZFS dataset.

File system mounts under parts of the hierarchy controlled by the global
zone are supported. For example, if an empty /usr/local directory
exists in the global zone, the zone administrator can mount other contents
under that directory.

You can use a delegated ZFS dataset for file systems that do not need
to be accessed during patching or upgrade, such as /export in
the non-global zone.

netmasks Warning Displayed When
Booting Zone

If you see the following message when you boot the zone as described
in How to Boot a Zone:

The message is only a warning, and the command has succeeded. The message
indicates that the system was unable to find the netmask to
be used for the IP address specified in the zone's configuration.

To stop the warning from displaying on subsequent reboots, ensure that
the correct netmasks databases are listed in the /etc/nsswitch.conf file in the global zone and that at least one of these databases
contains the subnet and netmasks to be used for the zone my-zone.

For example, if the /etc/inet/netmasks file and
the local NIS database are used for resolving netmasks in
the global zone, the appropriate entry in /etc/nsswitch.conf is
as follows:

netmasks: files nis

The subnet and corresponding netmask information for the zone my-zone can then be added to /etc/inet/netmasks for
subsequent use.

For more information about the netmasks command,
see the netmasks(4) man
page.

Zone Does Not Halt

In the event that the system state associated with the zone cannot be
destroyed, the halt operation will fail halfway. This leaves the zone in an
intermediate state, somewhere between running and installed. In this state
there are no active user processes or kernel threads, and none can be created.
When the halt operation fails, you must manually intervene to complete the
process.

The most common cause of a failure is the inability of the system to
unmount all file systems. Unlike a traditional Solaris system shutdown, which
destroys the system state, zones must ensure that no mounts performed while
booting the zone or during zone operation remain once the zone has been halted.
Even though zoneadm makes sure that there are no processes
executing in the zone, the unmount operation can fail if processes in the
global zone have open files in the zone. Use the tools described in the proc(1) (see pfiles) and fuser(1M) man pages to find these processes
and take appropriate action. After these processes have been dealt with, reinvoking zoneadmhalt will completely halt the zone.

Resolving Problems With a zoneadmattach Operation

Patches and Packages Are Out of Sync

The target system must be running the same or later versions of the
following required operating system packages and patches as those installed
on the original host.

Packages that deliver files under an inherit-pkg-dir resource

Packages where SUNW_PKG_ALLZONES=true

If packages and patches are different between the original host
and the new host, you might see a display similar to the following:

host2# zoneadm -z my-zone attach
These packages installed on the source system are inconsistent with this system:
SUNWgnome-libs (2.6.0,REV=101.0.3.2005.12.06.20.27) version mismatch
(2.6.0,REV=101.0.3.2005.12.19.21.22)
SUNWudaplr (11.11,REV=2005.12.13.01.06) version mismatch
(11.11,REV=2006.01.03.00.45)
SUNWradpu320 (11.10.0,REV=2005.01.21.16.34) is not installed
SUNWaudf (11.11,REV=2005.12.13.01.06) version mismatch
(11.11,REV=2006.01.03.00.45)
NCRos86r (11.10.0,REV=2005.01.17.23.31) is not installed
These packages installed on this system were not installed on the source system:
SUNWukspfw (11.11,REV=2006.01.03.00.45) was not installed
SUNWsmcmd (1.0,REV=2005.12.14.01.53) was not installed
These patches installed on the source system are inconsistent with this system:
120081 is not installed
118844 is not installed
118344 is not installed
These patches installed on this system were not installed on the source system:
118669 was not installed
118668 was not installed
116299 was not installed

If the new host has later versions of the zone-dependent packages
or their associated patches, use zoneadmattach with
the -u option to update those packages within the zone to
match the new host. See About Migrating a Zone.

Operating System Releases
Do Not Match

To migrate the zone successfully, install the same Solaris release that
is running on the original host on a system with the same architecture.

Verify the Solaris release running on the original system.

host1# uname -a

Install the same release on the new host.

Refer to
the Solaris installation documentation on docs.sun.com.

Machine
Architectures Do Not Match

To migrate the zone successfully, use the -u option
to zoneadmattach.

Verify the system architecture on both systems.

host1# uname -a

If the architectures are different, use the -u option
to zoneadmattach to perform the attach.