System Administration Guide: Virtualization Using the Solaris Operating System

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.

The chapter also covers the following general zones topics:

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


Note –

For information on branded zones, see Part III, Linux Branded Zones.

For information on using zones on a Solaris Trusted Extensions system, see Chapter 16, Managing Zones in Trusted Extensions (Tasks), in Solaris Trusted Extensions Administrator’s Procedures and Zones in Trusted Extensions in Solaris Trusted Extensions Transition Guide.


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:

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.

These concepts are discussed in Chapter 17, Planning and Configuring Non-Global Zones (Tasks).

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:

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

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

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

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

How Zones Work

A non-global zone can be thought of as a box. One or more applications can run in this box without interacting with the rest of the system. Solaris zones isolate software applications or services by using flexible, software-defined boundaries. Applications that are running in the same instance of the Solaris Operating System can then be managed independently of one other. Thus, different versions of the same application can be run in different zones, to match the requirements of your configuration.

A process assigned to a zone can manipulate, monitor, and directly communicate with other processes that are assigned to the same zone. The process cannot perform these functions with processes that are assigned to other zones in the system or with processes that are not assigned to a zone. Processes that are assigned to different zones are only able to communicate through network APIs.

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.

For information about zone configuration, see Chapter 16, Non-Global Zone Configuration (Overview). For information about zone installation, see Chapter 18, About Installing, Halting, Uninstalling, and Cloning Non-Global Zones (Overview). For information about zone login, see Chapter 20, Non-Global Zone Login (Overview).

Non-Global Zone State Model

A non-global zone can be in one of the following six states:

Configured

The zone's configuration is complete and committed to stable storage. However, those elements of the zone's application environment that must be specified after initial boot are not yet present.

Incomplete

During an install or uninstall operation, zoneadm sets the state of the target zone to incomplete. Upon successful completion of the operation, the state is set to the correct state.

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

Chapter 19, Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks) and the zoneadm(1M) man page describe how to use the zoneadm command to initiate transitions between these states.

Table 15–1 Commands That Affect Zone State

Current Zone State 

Applicable Commands 

Configured 

zonecfg -z zonename verify

zonecfg -z zonename commit

zonecfg -z zonename delete

zoneadm -z zonename attach

zoneadm -z zonename verify

zoneadm -z zonename install

zoneadm -z zonename clone

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

Incomplete 

zoneadm -z zonename uninstall

Installed 

zoneadm -z zonename ready (optional)

zoneadm -z zonename boot

zoneadm -z zonename uninstall uninstalls the configuration of the specified zone from the system.

zoneadm -z zonename move path

zoneadm -z zonename detach

zonecfg -z zonename can be used to add or remove an attr, bootargs, capped-memory, dataset, 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 -z zonename boot

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

zonecfg -z zonename can be used to add or remove attr, bootargs, capped-memory, dataset, capped-cpu, dedicated-cpu, device, fs, ip-type, limitpriv, net, rctl, or scheduling-class property. The inherit-pkg-dir resources cannot be changed.

Running 

zlogin options zonename

zoneadm -z zonename reboot

zoneadm -z zonename halt returns a ready zone to the installed state.

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

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

Granularity

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

Environment

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

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

Setting Up Zones on Your System (Task Map)

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

Task 

Description 

For Instructions 

Identify the applications that you would like to run in zones. 

Review the applications running on your system: 

  • Determine which applications are critical to your business goals.

  • Assess the system needs of the applications you are running.

Refer to your business goals and to your system documentation if necessary. 

Determine how many zones to configure. 

Assess: 

  • The performance requirements of the applications you intend to run in zones

  • The availability of the recommended 100 MB of free disk space per zone to be installed

 

See Evaluating the Current System Setup.

Determine whether you will use resource pools with your zone to create a container. 

If you are also using resource management features on your system, align the zones with the resource management boundaries. Configure resource pools before you configure zones. 

Note that you can add zone-wide resource controls and pool functionality to a zone quickly by using zonecfg properties.

See How to Configure the Zone, and Chapter 13, Creating and Administering Resource Pools (Tasks).

Perform the preconfiguration tasks. 

Determine the zone name and the zone path. Determine whether the zone will be a shared-IP zone or an exclusive-IP zone, and obtain IP addresses or the data-link name. Determine the required file systems and devices for each zone. Determine the scheduling class for the zone. Determine the set of privileges that processes inside the zone should be limited to, if the standard default set is not sufficient. Note that some zonecfg settings automatically add privileges. For example, ip-type=exclusive automatically adds multiple privileges required to configure and manage network stacks.

For information on the zone name and path, IP types, IP addresses, file systems, devices, scheduling class, and privileges, see Chapter 16, Non-Global Zone Configuration (Overview) and Evaluating the Current System Setup. For a listing of default privileges and privileges that can be configured in a non-global zone, see Privileges in a Non-Global Zone. For information about IP feature availability, see Networking in Shared-IP Non-Global Zones and Networking in Exclusive-IP Non-Global Zones.

Develop configurations. 

Configure non-global zones. 

See Configuring, Verifying, and Committing a Zone and the zonecfg(1M) man page.

As global administrator, verify and install configured zones. 

Zones must be verified and installed prior to login. 

See Chapter 18, About Installing, Halting, Uninstalling, and Cloning Non-Global Zones (Overview) and Chapter 19, Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks).

As global administrator, boot the non-global zones. 

Boot each zone to place the zone in the running state. 

See Chapter 18, About Installing, Halting, Uninstalling, and Cloning Non-Global Zones (Overview) and Chapter 19, Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks).

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.

See Chapter 20, Non-Global Zone Login (Overview) and Chapter 21, Logging In to Non-Global Zones (Tasks).

Prepare the new zone for production use. 

Create user accounts, add additional software, and customize the zone's configuration. 

Refer to the documentation you use to set up a newly installed machine. Special considerations applicable to a system with zones installed are covered in this guide. 

Chapter 16 Non-Global Zone Configuration (Overview)

This chapter provides an introduction to non-global zone configuration.

The following topics are covered in this chapter:

After you have learned about zone configuration, go to Chapter 17, Planning and Configuring Non-Global Zones (Tasks) to configure non-global zones for installation on your system.

For information about lx branded zone configuration, see Chapter 30, Planning the lx Branded Zone Configuration (Overview) and Chapter 31, Configuring the lx Branded Zone (Tasks).

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:

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:

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.

Resource Pool Association

If you have configured resource pools on your system as described in Chapter 13, Creating and Administering Resource Pools (Tasks), you can use the pool property to associate the zone with one of the resource pools when you configure the zone.

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:

importance

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:

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.


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.


For more information, see Chapter 10, Physical Memory Control Using the Resource Capping Daemon (Overview), Chapter 11, Administering the Resource Capping Daemon (Tasks), and How to Configure the Zone. To temporarily set a resource cap for a zone, see How to Specify a Temporary Resource Cap for a Zone.

Zone Network Interfaces

Zone network interfaces configured by the zonecfg command to provide network connectivity will automatically be set up and placed in the zone when it is booted.

The Internet Protocol (IP) layer accepts and delivers packets for the network. This layer includes IP routing, the Address Resolution Protocol (ARP), IP security architecture (IPsec), and IP Filter.

There are two IP types available for non-global zones, shared-IP and exclusive-IP. The shared-IP zone shares a network interface and the exclusive-IP zone must have a dedicated network interface.

For information about IP features in each type, see Networking in Shared-IP Non-Global Zones and Networking in Exclusive-IP Non-Global Zones.

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:

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 zonecfg net 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.


global# zlogin zone1 ifconfig -a

Security Differences Between Shared-IP and Exclusive-IP Non-Global Zones

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:

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

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.

Size (bytes) 

swap property of capped-memory

These limits can be specified for running processes by using the prctl command. An example is provided in How to Set FSS Shares in the Global Zone Using the prctl Command. Limits specified through the prctl command are not persistent. The limits are only in effect until the system is rebooted.

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:


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.


For more information, see Privileges in a Non-Global Zone, How to Configure the Zone, and privileges(5).

Including a Comment for a Zone

You can add a comment for a zone by using the attr resource type. For more information, see How to Configure the 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:

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:zonename:fs>

For more information, including procedures that show how to use the various zonecfg components described in this chapter, see Chapter 17, Planning and Configuring Non-Global Zones (Tasks).

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.

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 -t template 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.

See How to Configure the Zone and the zonecfg(1M) man page for more information.

set

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 – 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.

Path 

Description 

/home/export/my-zone

zonecfg zonepath

/home/export/my-zone/root

Root of the zone 

/home/export/my-zone/root/dev

Devices created for the zone 

See Traversing File Systems for a further discussion of this issue.


Note –

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.

limitpriv

This property is used to specify a privilege mask other than the default. See Privileges in a Non-Global Zone.

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:


global# zonecfg -z userzone
zonecfg:userzone> set limitpriv="default,dtrace_proc,dtrace_user"

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.

ip-type

This property is required to be set only if the zone is an exclusive-IP zone. See Exclusive-IP Non-Global Zones and How to Configure the Zone.

dedicated-cpu

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

  • As a delegated dataset

See Chapter 10, ZFS Advanced Topics, in Solaris ZFS Administration Guide and File Systems and Non-Global Zones.

Also see Chapter 28, Troubleshooting Miscellaneous Solaris Zones Problems for information on dataset issues.

fs

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.

See Setting Zone-Wide Resource Controls for more information.


Note –

To configure zone-wide controls using the set global_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.


zonecfg:my-zone> add dedicated-cpu
zonecfg:my-zone:dedicated-cpu> set ncpus=1-3
zonecfg:my-zone:dedicated-cpu> set importance=2
zonecfg:my-zone:dedicated-cpu> end
capped-cpu

ncpus

Specify the number of CPUs. The following example specifies a CPU cap of 3.5 CPUs for the zone my-zone.


zonecfg:my-zone> add capped-cpu
zonecfg:my-zone:capped-cpu> set ncpus=3.5
zonecfg:my-zone:capped-cpu> end
capped-memory

physical, swap, lockedSpecify the memory limits for the zone my-zone. Each limit is optional, but at least one must be set.


zonecfg:my-zone> add capped-memory
zonecfg:my-zone:capped-memory> set physical=50m
zonecfg:my-zone:capped-memory> set swap=100m
zonecfg:my-zone:capped-memory> set locked=30m
zonecfg:my-zone:capped-memory> end
fs

dir, special, raw, type, options

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.


zonecfg:my-zone> add fs
zonecfg:my-zone:fs> set dir=/mnt
zonecfg:my-zone:fs> set special=/dev/dsk/c0t0d0s2
zonecfg:my-zone:fs> set raw=/dev/rdsk/c0t0d0s2
zonecfg:my-zone:fs> set type=ufs
zonecfg:my-zone:fs> add options [nodevices,logging]
zonecfg:my-zone:fs> end

For more information, see The -o nosuid Option, Security Restrictions and File System Behavior, and the fsck(1M) and mount(1M) man pages. Also note that section 1M man pages are available for mount options that are unique to a specific file system. The names of these man pages have the form mount_filesystem.


Note –

To add a ZFS file system using the fs resource property, see Adding ZFS File Systems to a Non-Global Zone in Solaris ZFS Administration Guide.


dataset

name

The lines in the following example specify that the dataset sales is to be visible and mounted in the non-global zone and no longer visible in the global zone.


zonecfg:my-zone> add dataset
zonecfg:my-zone> set name=tank/sales
zonecfg:my-zone> end
inherit-pkg-dir

dir

The lines in the following example specify that /opt/sfw is to be loopback mounted from the global zone.


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

address, physical, defrouter


Note –

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.


zonecfg:my-zone> add net
zonecfg:my-zone:net> set physical=hme0
zonecfg:my-zone:net> set address=192.168.0.1
zonecfg:my-zone:net> set defrouter=10.0.0.1
zonecfg:my-zone:net> end

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 dladm show-link. Note that ip-type=exclusive must also be specified.


zonecfg:my-zone> set ip-type=exclusive
zonecfg:my-zone> add net
zonecfg:my-zone:net> set physical=bge32001
zonecfg:my-zone:net> end

Note –

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.


device

match

In the following example, a /dev/pts device is included in a zone.


zonecfg:my-zone> add device
zonecfg:my-zone:device> set match=/dev/pts*
zonecfg:my-zone:device> end

Note –

See Device Use in Non-Global Zones.


rctl

name, value

The following zone-wide resource controls are available.

  • zone.cpu-cap

  • zone.cpu-shares (preferred: cpu-shares)

  • zone.max-locked-memory

  • zone.max-lwps (preferred: max-lwps)

  • zone.max-msg-ids (preferred: max-msg-ids)

  • zone.max-sem-ids (preferred: max-sem-ids)

  • zone.max-shm-ids (preferred: max-shm-ids)

  • zone.max-shm-memory (preferred: max-shm-memory)

  • zone.max-swap

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 add rctl, 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.


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

zonecfg:my-zone> add rctl
zonecfg:my-zone:rctl> set name=zone.max-lwps
zonecfg:my-zone:rctl> add value (priv=privileged,limit=100,action=deny)
zonecfg:my-zone:rctl> end

For general information about resource controls and attributes, see Chapter 6, Resource Controls (Overview) and Resource Controls Used in Non-Global Zones.

attr

name, type, value

In the following example, a comment about a zone is added.


zonecfg:my-zone> add attr
zonecfg:my-zone:attr> set name=comment
zonecfg:my-zone:attr> set type=string
zonecfg:my-zone:attr> set value="Production zone"
zonecfg:my-zone:attr> end

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:

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.

For an introduction to the zone configuration process, see Chapter 16, Non-Global Zone Configuration (Overview).

For information about lx branded zone configuration, see Chapter 30, Planning the lx Branded Zone Configuration (Overview) and Chapter 31, Configuring the lx Branded Zone (Tasks).

Planning and Configuring a Non-Global Zone (Task Map)

Before you set up your system to use zones, you must first collect information and make decisions about how to configure the zones. The following task map summarizes how to plan and configure a zone.

Task 

Description 

For Instructions 

Plan your zone strategy. 

  • Evaluate the applications running on your system to determine which applications you want to run in a zone.

  • Assess the availability of disk space to hold the files that are unique in the zone.

  • If you are also using resource management features, determine how to align the zone with the resource management boundaries.

  • If you are using resource pools, configure the pools if necessary.

Refer to historical usage. Also see Disk Space Requirements and Resource Pools Used in Zones.

Determine the name for the zone. 

Decide what to call the zone based on the naming conventions. 

See Zone Configuration Data and Zone Host Name.

Determine the zone path. 

Each zone has a path to its root directory that is relative to the global zone's root directory. 

See Zone Configuration Data.

Evaluate the need for CPU restriction if you are not configuring resource pools. Note that with specification in zonecfg, pool settings propagate during migrations.

Review your application requirements. 

See dedicated-cpu Resource.

Evaluate the need for memory allocation if you plan to cap memory for the zone by using rcapd from the global zone.

Review your application requirements. 

See Chapter 10, Physical Memory Control Using the Resource Capping Daemon (Overview), Chapter 11, Administering the Resource Capping Daemon (Tasks), and Physical Memory Control and the capped-memory Resource.

Make the FSS the default scheduler on the system. 

Give each zone CPU shares to control the zone's entitlement to CPU resources. The FSS guarantees a fair dispersion of CPU resources among zones that is based on allocated shares. 

Chapter 8, Fair Share Scheduler (Overview), Scheduling Class.

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.

See Determine the Zone Host Name and the Network Requirements, How to Configure the Zone, and System Administration Guide: IP Services.

Determine which file systems you want to mount in the zone. 

Review your application requirements. 

See File Systems Mounted in Zones for more information.

Determine which network interfaces should be made available in the zone. 

Review your application requirements. 

See Shared-IP Network Interfaces for more information.

Determine whether you must alter the default set of non-global zone permissions. 

Check the set of privileges: default, privileges that can be added and removed, and privileges that cannot be used at this time. 

See Privileges in a Non-Global Zone.

Determine which devices should be configured in each zone. 

Review your application requirements. 

Refer to the documentation for your application. 

Configure the zone. 

Use zonecfg to create a configuration for the zone.

See Configuring, Verifying, and Committing a Zone.

Verify and commit the configured zone. 

Determine whether the resources and properties specified are valid on a hypothetical system. 

See Configuring, Verifying, and Committing a 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.

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:

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.

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 :

See How to Configure the Zone.


Restricting Zone Size

The following options can be used to restrict zone size:

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.

For more information, see TCP/IP Configuration Files in System Administration Guide: IP Services and Network Databases and the nsswitch.conf File in System Administration Guide: IP Services.

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:

16 bits of zero:upper 16 bits of IPv4 address:lower 16 bits of IPv4 address:a zone-unique number

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.

See sysidcfg(4) for more information.

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.

Figure 17–1 Loopback-Mounted File Systems

Illustration shows loopback-mounted file systems.

See the lofs(7S) man page for more information.

Creating, Revising, and Deleting Non-Global Zone Configurations (Task Map)

Task 

Description 

For Instructions 

Configure a non-global zone. 

Use the zonecfg command to create a zone, verify the configuration, and commit the configuration. You can also use a script to configure and boot multiple zones on your system.

You can use the zonecfg command to display the configuration of a non-global zone.

Configuring, Verifying, and Committing a Zone, Script to Configure Multiple Zones

Modify a zone configuration. 

Use these procedures to modify a resource type in a zone configuration, modify a property type such as the name of a zone, or add a dedicated device to a zone. 

Using the zonecfg Command to Modify a Zone Configuration

Revert a zone configuration or delete a zone configuration. 

Use the zonecfg command to undo a resource setting made to a zone configuration or to delete a zone configuration.

Using the zonecfg Command to Revert or Remove a Zone Configuration

Delete a zone configuration. 

Use the zonecfg command with the delete subcommand to delete a zone configuration from the system.

How to Delete a Zone Configuration

Configuring, Verifying, and Committing a Zone

You use the zonecfg command described in the zonecfg(1M) man page to perform the following actions.

The zonecfg command can also be used to persistently specify the resource management settings for the global zone.

While configuring a zone with the zonecfg utility, you can use the revert subcommand to undo the setting for a resource. See How to Revert a Zone Configuration.

A script to configure multiple zones on your system is provided in Script to Configure Multiple Zones.

To display a non-global zone's configuration, see How to Display the Configuration of a Non-Global Zone.

ProcedureHow 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.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Set up a zone configuration with the zone name you have chosen.

    The name my-zone is used in this example procedure.


    global# zonecfg -z my-zone
    

    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.
  3. Create the new zone configuration.

    This procedure uses the Sun default settings.


    zonecfg:my-zone> create
    
  4. Set the zone path, /export/home/my-zone in this procedure.


    zonecfg:my-zone> set zonepath=/export/home/my-zone
    
  5. 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
    
  6. Set persistent boot arguments for a zone.


    zonecfg:my-zone> set bootargs="-m verbose"
    
  7. Dedicate one CPU to this zone.


    zonecfg:my-zone> add dedicated-cpu
    
    1. Set the number of CPUs.


      zonecfg:my-zone:dedicated-cpu> set ncpus=1-2
      
    2. (Optional) Set the importance.


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

      The default is 1.

    3. End the specification.


      zonecfg:my-zone:dedicated-cpu> end
      
  8. 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.

  9. Set the scheduling class to FSS.


    zonecfg:my-zone> set scheduling-class=FSS
    
  10. Add a memory cap.


    zonecfg:my-zone> add capped-memory
    
    1. Set the memory cap.


      zonecfg:my-zone:capped-memory> set physical=50m
      
    2. Set the swap memory cap.


      zonecfg:my-zone:capped-memory> set swap=100m
      
    3. Set the locked memory cap.


      zonecfg:my-zone:capped-memory> set locked=30m
      
    4. End the memory cap specification.


      zonecfg:my-zone:capped-memory> end
      
  11. Add a file system.


    zonecfg:my-zone> add fs
    
    1. Set the mount point for the file system, /usr/local in this procedure.


      zonecfg:my-zone:fs> set dir=/usr/local
      
    2. 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.

    3. 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.

    4. 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.

  12. (Optional) Set the hostid.


    zonecfg:my-zone> set hostid=80f0c086
    
  13. Add a ZFS dataset named sales in the storage pool tank


    zonecfg:my-zone> add dataset
    
    1. Specify the path to the ZFS dataset sales.


      zonecfg:my-zone> set name=tank/sales
      
    2. End the dataset specification.


      zonecfg:my-zone> end
      
  14. (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
    
    1. 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.


    2. 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 zonecfg before 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


  15. (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.


  16. Add a network interface.


    zonecfg:my-zone> add net
    
    1. (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
      
    2. Set the physical device type for the network interface, the hme device in this procedure.


      zonecfg:my-zone:net> set physical=hme0
      
    3. (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
      
    4. End the specification.


      zonecfg:my-zone:net> end
      

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

  17. Add a device.


    zonecfg:my-zone> add device
    
    1. Set the device match, /dev/sound/* in this procedure.


      zonecfg:my-zone:device> set match=/dev/sound/*
      
    2. End the device specification.


      zonecfg:my-zone:device> end
      

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

  18. 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.

  19. Add a comment by using the attr resource type.


    zonecfg:my-zone> add attr
    
    1. Set the name to comment.


      zonecfg:my-zone:attr> set name=comment
      
    2. Set the type to string.


      zonecfg:my-zone:attr> set type=string
      
    3. Set the value to a comment that describes the zone.


      zonecfg:my-zone:attr> set value="This is my work zone."
      
    4. End the attr resource type specification.


      zonecfg:my-zone:attr> end
      
  20. Verify the zone configuration for the zone.


    zonecfg:my-zone> verify
    
  21. Commit the zone configuration for the zone.


    zonecfg:my-zone> commit
    
  22. 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.


global# zonecfg -z my-zone "create ; set zonepath=/export/home/my-zone"

Where to Go From Here

See Installing and Booting Zones to install your committed zone configuration.

Script to Configure Multiple Zones

You can use this script to configure and boot multiple zones on your system. The script takes the following parameters:

You must be the global administrator in the global zone to execute the script. The global administrator has superuser privileges in the global zone or assumes the Primary Administrator role.


#!/bin/ksh
#
# Copyright 2006 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
#ident	"%Z%%M%	%I%	%E% SMI"

if [[ -z "$1" || -z "$2" || -z "$3" ]]; then
	   echo "usage: $0 <#-of-zones> <zonename-prefix> <basedir>"
	   exit 2
fi

if [[ ! -d $3 ]]; then
  	echo "$3 is not a directory"
	   exit 1
fi

nprocs=`psrinfo | wc -l`
nzones=$1
prefix=$2
dir=$3

ip_addrs_per_if=`ndd /dev/ip ip_addrs_per_if`
if [ $ip_addrs_per_if -lt $nzones ]; then
	   echo "ndd parameter ip_addrs_per_if is too low ($ip_addrs_per_if)"
  	echo "set it higher with 'ndd -set /dev/ip ip_addrs_per_if <num>"
 	exit 1
fi

i=1
while [ $i -le $nzones ]; do
	zoneadm -z $prefix$i list > /dev/null 2>&1
	if [ $? != 0 ]; then
		echo configuring $prefix$i
		F=$dir/$prefix$i.config
		rm -f $F
		echo "create" > $F
		echo "set zonepath=$dir/$prefix$i" >> $F
		zonecfg -z $prefix$i -f $dir/$prefix$i.config 2>&1 | \
		    sed 's/^/    /g' 
	else
		echo "skipping $prefix$i, already configured"
	fi
	i=`expr $i + 1`
done

i=1
while [ $i -le $nzones ]; do
	j=1
	while [ $j -le $nprocs ]; do
		if [ $i -le $nzones ]; then
			if [ `zoneadm -z $prefix$i list -p | \
			    cut -d':' -f 3` != "configured" ]; then
				echo "skipping $prefix$i, already installed"
			else
				echo installing $prefix$i
				mkdir -pm 0700 $dir/$prefix$i
				chmod 700 $dir/$prefix$i
				zoneadm -z $prefix$i install > /dev/null 2>&1 &
				sleep 1	# spread things out just a tad
			fi
		fi
		i=`expr $i + 1`
		j=`expr $j + 1`
	done
	wait
done

i=1
while [ $i -le $nzones ]; do
	echo setting up sysid for $prefix$i
	cfg=$dir/$prefix$i/root/etc/sysidcfg
	rm -f $cfg
	echo "network_interface=NONE {hostname=$prefix$i}" > $cfg
	echo "system_locale=C" >> $cfg
	echo "terminal=xterms" >> $cfg
	echo "security_policy=NONE" >> $cfg
	echo "name_service=NONE" >> $cfg
	echo "timezone=US/Pacific" >> $cfg
	echo "root_password=Qexr7Y/wzkSbc" >> $cfg  # 'l1a'
	i=`expr $i + 1`
done

i=1
para=`expr $nprocs \* 2`
while [ $i -le $nzones ]; do
	date
	j=1
	while [ $j -le $para ]; do
		if [ $i -le $nzones ]; then
			echo booting $prefix$i
			zoneadm -z $prefix$i boot &
		fi
		j=`expr $j + 1`
		i=`expr $i + 1`
	done
	wait
done

ProcedureHow to Display the Configuration of a Non-Global Zone

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Display the configuration of a zone.


    global# zonecfg -z zonename info
    

Using the zonecfg Command to Modify a Zone Configuration

You can also use the zonecfg command to do the following:

ProcedureHow to Modify a Resource Type in a Zone Configuration

You can select a resource type and modify the specification for that resource.

Note that the contents of software packages in the inherit-pkg-dir directory cannot be modified or removed after the zone has been installed with zoneadm.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Select the zone to be modified, my-zone in this procedure.


    global# zonecfg -z my-zone
    
  3. Select the resource type to be changed, for example, a resource control.


    zonecfg:my-zone> select rctl name=zone.cpu-shares
    
  4. Remove the current value.


    zonecfg:my-zone:rctl> remove value (priv=privileged,limit=20,action=none)
    
  5. Add the new value.


    zonecfg:my-zone:rctl> add value (priv=privileged,limit=10,action=none)
    
  6. End the revised rctl specification.


    zonecfg:my-zone:rctl> end
    
  7. Commit the zone configuration for the zone.


    zonecfg:my-zone> commit
    
  8. 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.

    Committed changes made through zonecfg take effect the next time the zone is booted.

ProcedureHow to Clear a Property Type in a Zone Configuration

Use this procedure to reset a standalone property.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Select the zone to be modified, my-zone in this procedure.


    global# zonecfg -z my-zone
    
  3. Clear the property to be changed, the existing pool association in this procedure.


    zonecfg:my-zone> clear pool
    
  4. Commit the zone configuration for the zone.


    zonecfg:my-zone> commit
    
  5. 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.

    Committed changes made through zonecfg take effect the next time the zone is booted.

ProcedureHow to Rename a Zone

This procedure can be used to rename zones that are in either the configured state or the installed state.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Select the zone to be renamed, my-zone in this procedure.


    global# zonecfg -z my-zone
    
  3. Change the name of the zone, for example, to newzone.


    zonecfg:my-zone> set zonename=newzone
    
  4. Commit the change.


    zonecfg:newzone> commit
    
  5. Exit the zonecfg command.


    zonecfg:newzone> exit
    

    Committed changes made through zonecfg take effect the next time the zone is booted.

ProcedureHow to Add a Dedicated Device to a Zone

The following specification places a scanning device in a non-global zone configuration.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Add a device.


    zonecfg:my-zone> add device
    
  3. Set the device match, /dev/scsi/scanner/c3t4* in this procedure.


    zonecfg:my-zone:device> set match=/dev/scsi/scanner/c3t4*
    
  4. End the device specification.


    zonecfg:my-zone:device> end
    
  5. Exit the zonecfg command.


    zonecfg:my-zone> exit
    

ProcedureHow to Set zone.cpu-shares in the Global Zone

This procedure is used to persistently set shares in the global zone.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Use the zonecfg command .


    # zonecfg -z global
    
  3. Set five shares for the global zone.


    zonecfg:global> set cpu-shares=5
    
  4. Exit zonecfg.


    zonecfg:global> exit
    

Using the zonecfg Command to Revert or Remove a Zone Configuration

Use the zonecfg command described in zonecfg(1M) to revert a zone's configuration or to delete a zone configuration.

ProcedureHow to Revert a Zone Configuration

While configuring a zone with the zonecfg utility, use the revert subcommand to undo a resource setting made to the zone configuration.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. While configuring a zone called tmp-zone, type info to view your configuration:


    zonecfg:tmp-zone> info
    

    The net resource segment of the configuration displays as follows:


    .
    .
    .
    fs:
            dir: /tmp
            special: swap
            type: tmpfs
    net:
            address: 192.168.0.1
            physical: eri0
    device
            match: /dev/pts/*
    .
    .
    .
  3. Remove the net address:


    zonecfg:tmp-zone> remove net address=192.168.0.1
    
  4. Verify that the net entry has been removed.


    zonecfg:tmp-zone> info
    

    .
    .
    .
    fs:
            dir: /tmp
            special: swap
            type: tmpfs
    device
            match: /dev/pts/*
    .
    .
    .
  5. Type revert.


    zonecfg:tmp-zone> revert
    
  6. Answer yes to the following question:


    Are you sure you want to revert (y/[n])? y
    
  7. Verify that the net address is once again present:


    zonecfg:tmp-zone> info
    

    .
    .
    .
    fs:
            dir: /tmp
            special: swap
            type: tmpfs
    net:
            address: 192.168.0.1
            physical: eri0
    device
            match: /dev/pts/*
    .
    .
    .

ProcedureHow to Delete a Zone Configuration

Use zonecfg with the delete subcommand to delete a zone configuration from the system.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Delete the zone configuration for the zone a-zone by using one of the following two methods:

    • Use the -F option to force the action:


      global# zonecfg -z a-zone delete -F
      
    • Delete the zone interactively by answering yes to the system prompt:


      global# zonecfg -z a-zone delete
      Are you sure you want to delete zone a-zone (y/[n])? y
      

Chapter 18 About Installing, Halting, Uninstalling, and Cloning Non-Global Zones (Overview)

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.

The following topics are addressed in this chapter:

To clone a non-global zone, install and boot a non-global zone, or to halt or uninstall a non-global zone, see Chapter 19, Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks).

For information about lx branded zone installation, see Chapter 32, About Installing, Booting, Halting, Cloning, and Uninstalling lx Branded Zones (Overview) and Chapter 33, Installing, Booting, Halting, Uninstalling and Cloning lx Branded Zones (Tasks).

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:

For zone installation and verification procedures, see Chapter 19, Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks) and the zoneadm(1M) man page. Also refer to the zoneadm(1M) man page for supported options to the zoneadm list command. For zone configuration procedures, see Chapter 17, Planning and Configuring Non-Global Zones (Tasks) and the zonecfg(1M) man page. Zone states are described in Non-Global Zone State Model.

If you plan to produce Solaris auditing records for zones, read Using Solaris Auditing in Zones before you install non-global zones.

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.

A non-global zone is installed with the limited networking configuration (generic_limited_net.xml). Network configuration types are described in Chapter 17, Managing Services (Tasks), in System Administration Guide: Basic Administration. The zone administrator can switch the zone to the open, traditional networking configuration (generic_open.xml) by using the netservices command. Specific services can be enabled or disabled by using SMF commands. For more information, see Switching the Non-Global Zone to a Different Networking Service Configuration.

A successfully installed zone is ready for booting and initial login.

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:

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

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:

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.

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:

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 zoneadm halt command is used to remove both the application environment and the virtual platform for a zone. The zone is then brought back to the installed state. All processes are killed, devices are unconfigured, network interfaces are destroyed, file systems are unmounted, and the kernel data structures are destroyed.

The halt command does not run any shutdown scripts within the zone. To shut down a zone, see How to Use zlogin to Shut Down a Zone.

If the halt operation fails, see Zone Does Not Halt.

Rebooting a Zone

The zoneadm reboot 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 zoneadm boot and reboot commands:

The following definitions apply:

-i altinit

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).

-m smf_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.

Message options include the following:

quiet

Prints standard per-service output and error messages requiring administrative intervention

verbose

Prints standard per-service output and messages providing more information.

-s

Boots only to milestone svc:/milestone/single-user:default. This milestone is equivalent to init level s.

For usage examples, see How to Boot a Zone and How to Boot a Zone in Single-User Mode.

For information on the Solaris service management facility (SMF) and init , see Chapter 16, Managing Services (Overview), in System Administration Guide: Basic Administration, svc.startd(1M) and init(1M).

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

When the source zonepath and the target zonepath both reside on ZFS and are in the same pool, the zoneadm clone 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 cannot use manual snapshots, such as the type described in Creating and Destroying ZFS Snapshots in Solaris ZFS Administration Guide. This type of snapshot lacks the data to perform a validation.

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.


See Cloning a Non-Global Zone on the Same System for more information.

Chapter 19 Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks)

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.

For general information about zone installation and related operations, see Chapter 18, About Installing, Halting, Uninstalling, and Cloning Non-Global Zones (Overview).

For information about lx branded zone installation and cloning, see Chapter 32, About Installing, Booting, Halting, Cloning, and Uninstalling lx Branded Zones (Overview) and Chapter 33, Installing, Booting, Halting, Uninstalling and Cloning lx Branded Zones (Tasks).

Zone Installation (Task Map)

Task 

Description 

For Instructions 

(Optional) Verify a configured zone prior to installing the zone. 

Ensure that a zone meets the requirements for installation. If you skip this procedure, the verification is performed automatically when you install the zone. 

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

Install a configured zone. 

Install a zone that is in the configured state. 

How to Install a Configured Zone

Obtain the universally unique identifier (UUID) for the zone. 

This separate identifier, assigned when the zone is installed, is an alternate way to identify a zone. 

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

(Optional) Transition an installed zone to the ready state. 

You can skip this procedure if you want to boot the zone and use it immediately. 

(Optional) How to Transition the Installed Zone to the Ready State

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. Note that you must perform the internal zone configuration when you log in to the zone after booting it for the first time. 

How to Boot a Zone, Internal Zone Configuration, Performing the Initial Internal Zone Configuration

Boot a zone in single-user mode. 

Boots only to milestone svc:/milestone/single-user:default. This milestone is equivalent to init level s. See the init(1M) and svc.startd(1M) man pages.

How to Boot a Zone in Single-User Mode

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.

Procedure(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.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. 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.

ProcedureHow 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 zoneadm install command automatically creates a ZFS file system (dataset) for the zonepath when the zone is installed. You can block this action by including the -x nodataset parameter.


  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Install the configured zone my-zone by using the zoneadm command with the install option.

    • Install the zone, automatically creating a ZFS file system if the zonepath is on ZFS.


      global# zoneadm -z my-zone install
      

      The system will display:


      A ZFS file systm has been created for this zone.
    • Install the zone that has a zonepath on ZFS, but do not automatically create the ZFS file system.


      global# zoneadm -z my-zone install -x nodataset
      

    You will see various messages as the files and directories needed for the zone's root file system are installed under the zone's root path.

  3. (Optional) If an error message is displayed and the zone fails to install, type the following to get the zone state:


    global# zoneadm -z my-zone list -v
    
    • If the state is listed as configured, make the corrections specified in the message and try the zoneadm install command again.

    • If the state is listed as incomplete, first execute this command:


      global# zoneadm -z my-zone uninstall
      

      Then make the corrections specified in the message, and try the zoneadm install command again.

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


    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
     -  my-zone  installed    /export/home/my-zone           native     shared
Troubleshooting

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.

Next Steps

This zone was installed with the minimal network configuration described in Chapter 17, Managing Services (Tasks), in System Administration Guide: Basic Administration by default. You can switch to the open network configuration, or enable or disable individual services, when you log in to the zone. See Switching the Non-Global Zone to a Different Networking Service Configuration for details.

ProcedureHow 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.

  1. View the UUIDs for zones that have been installed.


    global# zoneadm list -p
    

    You will see a display similar to the following:


    0:global:running:/:native
    6:my-zone:running:/export/home/my-zone:61901255-35cf-40d6-d501-f37dc84eb504:native

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


global# zoneadm -z my-zone -u 61901255-35cf-40d6-d501-f37dc84eb504 list -v

If both -u uuid-match and -z zonename 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.

See Also

For more information, see zoneadm(1M) and libuuid(3LIB).

ProcedureHow to Mark an Installed Non-Global Zone Incomplete

If administrative changes on the system have rendered a zone unusable or inconsistent, it is possible to change the state of an installed zone to incomplete.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Mark the zone testzone incomplete.


    global# zoneadm -z testzone mark incomplete
    
  3. Use the list subcommand with the -i and -v options to verify the status.


    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
     -  my-zone  installed    /export/home/my-zone           native     shared
     -  testzone incomplete   /export/home/testzone          native     shared
Marking a Zone Incomplete

The -R root option can be used with the mark and list subcommands of zoneadm to specify an alternate boot environment. See zoneadm(1M) for more information.


Note –

Marking a zone incomplete is irreversible. The only action that can be taken on a zone marked incomplete is to uninstall the zone and return it to the configured state. See How to Uninstall a Zone.


Procedure(Optional) How to Transition the Installed Zone to the Ready State

Transitioning into the ready state prepares the virtual platform to begin running user processes. Zones in the ready state do not have any user processes executing in them.

You can skip this procedure if you want to boot the zone and use it immediately. The transition through the ready state is performed automatically when you boot the zone.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Use the zoneadm command with the -z option, the name of the zone, which is my-zone, and the ready subcommand to transition the zone to the ready state.


    global# zoneadm -z my-zone ready
    
  3. At the prompt, use the zoneadm list command with the -v option to verify the status.


    global# zoneadm list -v
    

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


    ID  NAME     STATUS       PATH                           BRAND      IP
     0  global   running      /                              native     shared
     1  my-zone  ready        /export/home/my-zone           native     shared

    Note that the unique zone ID 1 has been assigned by the system.

ProcedureHow 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.


Tip –

Note that you perform the internal zone configuration when you initially log in to the zone. This is described in Performing the Initial Internal Zone Configuration.

If you plan to use an /etc/sysidcfg file to perform initial zone configuration, as described in How to Use an /etc/sysidcfg File to Perform the Initial Zone Configuration, create the sysidcfg file and place it the zone's /etc directory before you boot the zone.


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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

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


    global# zoneadm -z my-zone boot
    
  3. When the boot completes, use the list subcommand with the -v option to verify the status.


    global# zoneadm list -v
    

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


    ID  NAME     STATUS       PATH                           BRAND      IP
     0  global   running      /                              native     shared
     1  my-zone  running      /export/home/my-zone           native     shared

Example 19–2 Specifying Boot Arguments for Zones

Boot a zone using the -m verbose option:


global# zoneadm -z my-zone boot -- -m verbose

Reboot a zone using the -m verbose boot option:


global# zoneadm -z my-zone reboot -- -m verbose

Zone administrator reboot of the zone my-zone, using the -m verbose 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.

ProcedureHow to Boot a Zone in Single-User Mode

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Boot the zone in single-user mode.


    global# zoneadm -z my-zone boot -- -s
    

Where to Go From Here

To log in to the zone and perform the initial internal configuration, see Chapter 20, Non-Global Zone Login (Overview) and Chapter 21, Logging In to Non-Global Zones (Tasks).

Halting, Rebooting, Uninstalling, Cloning, and Deleting Non-Global Zones (Task Map)

Task 

Description 

For Instructions 

Halt a zone. 

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.

How to Halt a Zone

Reboot a zone. 

The reboot procedure halts the zone and then boots it again. 

How to Reboot a Zone

Uninstall a zone. 

This procedure removes all of the files in the zone's root file system. Use this procedure with caution. The action is irreversible.

How to Uninstall a Zone

Provision a new non-global zone based on the configuration of an existing zone on the same system. 

Cloning a zone is an alternate, faster method of installing a zone. You must still configure the new zone before you can install it. 

Cloning a Non-Global Zone on the Same System

Delete a non-global zone from the system. 

This procedure completely removes a zone from a system. 

Deleting a Non-Global Zone From the System

Halting, Rebooting, and Uninstalling Zones

ProcedureHow to Halt a Zone

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

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. List the zones running on the system.


    global# zoneadm list -v
    

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


    ID  NAME     STATUS       PATH                           BRAND      IP
     0  global   running      /                              native     shared
     1  my-zone  running      /export/home/my-zone           native     shared
  3. Use the zoneadm command with the -z option, the name of the zone, for example, my-zone, and the halt subcommand to halt the given zone.


    global# zoneadm -z my-zone halt
    
  4. List the zones on the system again, to verify that my-zone has been halted.


    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
     -  my-zone  installed    /export/home/my-zone           native     shared
  5. Boot the zone if you want to restart it.


    global# zoneadm -z my-zone boot
    
Troubleshooting

If the zone does not halt properly, see Zone Does Not Halt for troubleshooting tips.

ProcedureHow to Reboot a Zone

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. List the zones running on the system.


    global# zoneadm list -v
    

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


    ID  NAME     STATUS       PATH                           BRAND      IP
     0  global   running      /                              native     shared
     1  my-zone  running      /export/home/my-zone           native     shared
  3. Use the zoneadm command with the -z reboot option to reboot the zone my-zone.


    global# zoneadm -z my-zone reboot
    
  4. List the zones on the system again to verify that my-zone has been rebooted.


    global# zoneadm list -v
    

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


    ID  NAME     STATUS       PATH                           BRAND      IP
     0  global   running      /                              native     shared
     2  my-zone  running      /export/home/my-zone           native     shared

    Tip –

    Note that the zone ID for my-zone has changed. The zone ID generally changes after a reboot.


ProcedureHow to Uninstall a Zone


Caution – Caution –

Use this procedure with caution. The action of removing all of the files in the zone's root file system is irreversible.


The zone cannot be in the running state. The uninstall operation is invalid for running zones.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. List the zones on the system.


    global# zoneadm list -v
    

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


    ID  NAME     STATUS       PATH                           BRAND      IP
     0  global   running      /                              native     shared
     -  my-zone  installed    /export/home/my-zone           native     shared
  3. Use the zoneadm command with the -z uninstall 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.

  4. 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 zoneadm uninstall 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 zoneadm clone command automatically uses ZFS to clone the zone. However, you can specify that the ZFS zonepath be copied and not ZFS cloned.

ProcedureHow to Clone a Zone

You must configure the new zone before you can install it. The parameter passed to the zoneadm create 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.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

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


    global# zoneadm -z my-zone halt
    
  3. 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.


  4. 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.

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


    global# zonecfg -z zone1 -f /export/zones/master
    
  6. 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.
  7. List the zones on the system.


    ID  NAME     STATUS       PATH                           BRAND      IP
     0  global   running      /                              native     shared
     -  my-zone  installed    /export/home/my-zone           native     shared
     -  zone1    installed    /export/home/zone1             native     shared
When a Source zonepath on a ZFS File System Is Cloned

When the zoneadm command clones a source zonepath that is on its own ZFS file system, the following actions are performed:

ProcedureHow to Clone a Zone from an Existing Snapshot

You can clone a source zone multiple times from an existing snapshot that was originally taken when you cloned a zone.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Configure the zone zone2.

  3. Specify that an existing snapshot be used to create new-zone2.


    global# zoneadm -z zone2 clone -s zeepool/zones/my-zone@SUNWzone1 my-zone
    

    The system displays:


    Cloning snapshot zeepool/zones/my-zone@SUNWzone1

    The zoneadm command validates the software from the snapshot SUNWzone1, and clones the snapshot.

  4. List the zones on the system.


    ID  NAME     STATUS       PATH                           BRAND      IP
     0  global   running      /                              native     shared
     -  my-zone  installed    /zeepool/zones/my-zone         native     shared
     -  zone1    installed    /zeepool/zones/zone1           native     shared
     -  zone2    installed    /zeepool/zones/zone2           native     shared

ProcedureHow to Use Copy Instead of ZFS Clone

Use this procedure to prevent the automatic cloning of a zone on a ZFS file system by specifying that the zonepath should be copied instead.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Specify that the zonepath on ZFS be copied and not ZFS cloned.


    global# zoneadm -z zone1 clone -m copy my-zone
    

Deleting a Non-Global Zone From the System

The procedure described in this section completely deletes a zone from a system.

ProcedureHow to Remove a Non-Global Zone

  1. Shut down the zone my-zone.


    global# zlogin my-zone shutdown -y -g0 -i0
    my-zone
  2. Remove the root file system for my-zone.


    global# zoneadm -z my-zone uninstall -F
    
  3. Delete the configuration for my-zone.


    global# zonecfg -z my-zone delete -F
    
  4. List the zones on the system, 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

Chapter 20 Non-Global Zone Login (Overview)

This chapter discusses logging in to zones from the global zone.

The following topics are covered in this chapter:

For procedures and usage information, see Chapter 21, Logging In to Non-Global Zones (Tasks).

For information about logging into lx branded zones, see Chapter 34, Logging In to lx Branded Zones (Tasks).

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:

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 user zonename

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.

For more information about changing the network profile or using SMF commands to add services to zones, see Switching the Non-Global Zone to a Different Networking Service Configuration. For more information about login commands, see rlogin(1), ssh(1), and telnet(1)

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.

For an introduction to the zone login process, see Chapter 20, Non-Global Zone Login (Overview).

For information about logging into lx branded zones, see Chapter 34, Logging In to lx Branded Zones (Tasks).

Initial Zone Boot and Zone Login Procedures (Task Map)

Task 

Description 

For Instructions 

Perform the internal configuration. 

Log in to the zone console or use an /etc/sysidcfg file to perform the initial zone configuration.

Performing the Initial Internal Zone Configuration

Log in to the 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. 

Logging In to a Zone

Exit a non-global zone. 

Disconnect from a non-global zone. 

How to Exit a Non-Global Zone

Shut down a zone. 

Shut down a zone by using the shutdown utility or a script.

How to Use zlogin to Shut Down a Zone

Print the zone name. 

Print the zone name of the current zone. 

Printing the Name of the Current Zone

Performing the Initial Internal Zone Configuration

You must configure the zone using one of the following methods:


Tip –

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.


global# zonecfg -z my-zone export > my-zone.config

See How to Restore an Individual Non-Global Zone for more information.


ProcedureHow to Log In to the Zone Console to Perform the Internal Zone Configuration

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Use the zlogin command with the -C option and the name of the zone, my-zone in this procedure.


    global# zlogin -C my-zone
    
  3. From another terminal window, boot the zone.


    global# zoneadm -z my-zone boot
    

    You will see a display similar to the following in the zlogin window:


    [NOTICE: Zone booting up]
  4. The first time you log in to the console, you are prompted to answer a series of questions. Your screen will look similar to this:


    SunOS Release 5.10 Version Generic 64-bit
    Copyright 1983-2006 Sun Microsystems, Inc.  All rights reserved.
    Use is subject to license terms.
    Hostname: my-zone
    Loading smf(5) service descriptions: 114/114
    Select a Language
    
         1. English
         2. es
         2. fr
    
    Please make a choice (1 - 3), or press h or ? for help:
    
    Select a Locale
    
          1. English (C - 7-bit ASCII)
          2. Canada (English) (UTF-8)
          4. U.S.A. (UTF-8)
          5. U.S.A. (en_US.ISO8859-1)
          6. U.S.A. (en_US.ISO8859-15)
          7. Go Back to Previous Screen
          
    Please make a choice (1 - 7), or press h or ? for help:
    
    What type of terminal are you using?
          1) ANSI Standard CRT
          2) DEC VT52
          3) DEC VT100
          4) Heathkit 19
          5) Lear Siegler ADM31
          6) PC Console
          7) Sun Command Tool
          8) Sun Workstation
          9) Televideo 910
          10) Televideo 925
          11) Wyse Model 50
          12) X Terminal Emulator (xterms)
          13) CDE Terminal Emulator (dtterm)
          14) Other
    Type the number of your choice and press Return:
    13
    .
    .
    .

    For the complete list of questions you must answer, see Internal Zone Configuration.

  5. (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.

ProcedureHow 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.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. From the global zone, change directories to the non-global zone's /etc directory:


    global# cd /export/home/my-zone/root/etc
    
  3. Create the sysidcfg file and place it in this directory.

    The file will look similar to the following:

    • For a shared-IP zone:


      system_locale=C
      terminal=dtterm
      network_interface=primary {
      	        hostname=my-zone
      }
      security_policy=NONE
      name_service=NIS {
      	        domain_name=special.example.com
      	        name_server=bird(192.168.112.3)
      }
      nfs4_domain=domain
      timezone=US/Central
      root_password=m4qtoWN
    • For an exclusive-IP zone with a static IP configuration:


      system_locale=C
      terminal=dtterm
      network_interface=primary {
               hostname=my-zone
               default_route=10.10.10.1
               ip_address=10.10.10.13
               netmask=255.255.255.0
      }
      nfs4_domain=domain
      timezone=US/Central
      root_password=m4qtoWN
    • For an exclusive-IP zone with DHCP and IPv6 option:


      system_locale=C
      terminal=dtterm
      network_interface=primary {
      	        dhcp protocol_ipv6=yes
      }
      security_policy=NONE
      name_service=DNS {
               domain_name=example.net
               name_server=192.168.224.11,192.168.224.33
      }
      nfs4_domain=domain
      timezone=US/Central
      root_password=m4qtoWN
  4. 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.

  5. Boot the zone.

See Also

See the sysidcfg(4) man page for more information.

Logging In to a Zone

Use the zlogin command to log in from the global zone to any zone that is running or in the ready state. See the zlogin(1) man page for more information.

You can log in to a zone in various ways, as described in the following procedures. You can also log in remotely, as described in Remote Login.

ProcedureHow to Log In to the Zone Console

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Use the zlogin command with the -C option and the name of the zone, for example, my-zone.


    global# zlogin -C my-zone
    

    Note –

    If you start the zlogin session immediately after issuing the zoneadm boot command, boot messages from the zone will display:


    SunOS Release 5.10 Version Generic 64-bit
    Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved.
    Use is subject to license terms.
    starting rpc services: rpcbind done.
    syslog service starting.
    The system is ready.

  3. When the zone console displays, log in as root, press Return, and type the root password when prompted.


    my-zone console login: root
    Password:

ProcedureHow to Use Interactive Mode to Access a Zone

In interactive mode, a new pseudo-terminal is allocated for use inside the zone.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. From the global zone, log in to the zone, for example, my-zone.


    global# zlogin my-zone
    

    Information similar to the following will display:


    [Connected to zone 'my-zone' pts/2]
    Last login: Wed Jul  3 16:25:00 on console
    Sun Microsystems Inc. SunOS 5.10 Generic July 2004
  3. Type exit to close the connection.

    You will see a message similar to the following:


    [Connection to zone 'my-zone' pts/2 closed]

ProcedureHow to Use Non-Interactive Mode to Access a Zone

Non-interactive mode is enabled when the user supplies a command to be run inside the zone. Non-interactive mode does not allocate a new pseudo-terminal.

Note that the command or any files that the command acts upon cannot reside on NFS.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. From the global zone, log in to the my-zone zone and supply a command name.

    The command zonename is used here.


    global# zlogin my-zone zonename
    

    You will see the following output:


    my-zone

ProcedureHow to Exit a Non-Global Zone

  1. To disconnect from a non-global zone, use one of the following methods.

    • To exit the zone non-virtual console:


      zonename# exit
      
    • To disconnect from a zone virtual console, use the tilde (~) character and a period:


      zonename# ~.
      

      Your screen will look similar to this:


      [Connection to zone 'lx-zone' pts/6 closed]
See Also

For more information about zlogin command options, see the zlogin(1) man page.

ProcedureHow to Use Failsafe Mode to Enter a Zone

When a connection to the zone is denied, the zlogin command can be used with the -S option to enter a minimal environment in the zone.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. 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
    

ProcedureHow to Use zlogin to Shut Down a Zone


Note –

Running init 0 in the global zone to cleanly shut down a Solaris system also runs init 0 in each of the non-global zones on the system. Note that init 0 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.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Log in to the zone to be shut down, for example, my-zone, and specify shutdown as the name of the utility and init 0 as the state.


    global# zlogin my-zone shutdown  -y -g0 -i0
    

    Your site might have its own shutdown script, tailored for your specific environment.


    Note –

    You cannot use the shutdown command to place the zone in single-user state at this time. See 6214427 for more information.


Using shutdown in Non-Interactive Mode

You cannot use the shutdown command in non-interactive mode to place the zone in single-user state at this time. See 6214427 for more information.

You can use an interactive login as described in How to Use Interactive Mode to Access a Zone.

Switching the Non-Global Zone to a Different Networking Service Configuration

This zone was installed with the minimal networking service configuration described in Chapter 17, Managing Services (Tasks), in System Administration Guide: Basic Administration. You can switch the zone to the open networking service configuration, or enable or disable individual services in the zone.

ProcedureHow to Switch the Zone to the Open Networking Service Configuration

  1. From the global zone, log in to the zone, for example, my-zone.


    global# zlogin my-zone
    
  2. Run the netservices command to switch the zone to the traditional open networking configuration.


    my-zone# /usr/sbin/netservices open
    

    You will see a display similar to the following. Respond y to the prompt to restart dtlogin.


    restarting syslogd
    restarting sendmail
    dtlogin needs to be restarted. Restart now? [Y] y
    restarting dtlogin

ProcedureHow to Enable a Specific Service in a Zone

  1. From the global zone, log in to the zone, for example, my-zone.


    global# zlogin my-zone
    
  2. Run the svcadm command to enable rlogin.


    my-zone# svcadm enable svc:/network/login:rlogin
    
  3. List the services to verify that rlogin is enabled.


    my-zone# svcs -a
    .
    .
    .
    online     14:01:08 svc:/network/login:rlogin
    .
    .
    .
    

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:

If the new host has later versions of the zone-dependent packages or the associated patches, using zoneadm attach 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.

This option only applies to zone brands using SVR4 packaging.

For information on moving and migrating lx branded zones, see Chapter 35, Moving and Migrating lx Branded Zones (Tasks).

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.

ProcedureHow to Move a Zone

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Halt the zone to be moved, db-zone in this procedure.


    global# zoneadm -z db-zone halt
    
  3. Use the zoneadm command with the move subcommand to move the zone to a new zonepath, /export/zones/db-zone.


    global# zoneadm -z db-zone move /export/zones/db-zone
    
  4. Verify the path.


    ID  NAME     STATUS       PATH                           BRAND      IP
     0  global   running      /                              native     shared
     -  my-zone  installed    /export/home/my-zone           native     shared
     -  db-zone  installed    /export/zones/db-zone          native     shared

Migrating a Non-Global Zone to a Different Machine

Note that you can do a trial run of a zone migration before you actually move the zone to a different machine. For more information, see About Validating a Zone Migration Before the Migration Is Performed.

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:

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


#uname -m

The zoneadm detach process creates the information necessary to attach the zone on a different system. The zoneadm attach 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.

ProcedureHow to Migrate A Non-Global Zone

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Halt the zone to be migrated, my-zone in this procedure.


    host1# zoneadm -z my-zone halt
    
  3. Detach the zone.


    host1# zoneadm -z my-zone detach
    

    The detached zone is now in the configured state.

  4. Move the zonepath for my-zone to the new host.

    See How to Move the zonepath to a new Host for more information.

  5. On the new host, configure the zone.


    host2# zonecfg -z my-zone
    

    You will see the following system message:


    my-zone: No such zone configured
    Use 'create' to begin configuring a new zone.
  6. To create the zone my-zone on the new host, use the zonecfg command with the -a option and the zonepath on the new host.


    zonecfg:my-zone> create -a /export/zones/my-zone
    
  7. (Optional) View the configuration.


    zonecfg:my-zone> info
    zonename: my-zone
    zonepath: /export/zones/my-zone
    autoboot: false
    pool:
    inherit-pkg-dir:
             dir: /lib
    inherit-pkg-dir:
             dir: /platform
    inherit-pkg-dir:
             dir: /sbin
    inherit-pkg-dir:
             dir: /usr
    net:
             address: 192.168.0.90
             physical: bge0
  8. Make any required adjustments to the configuration.

    For example, the network physical device is different on the new host, or devices that are part of the configuration might have different names on the new host.


    zonecfg:my-zone> select net physical=bge0
    zonecfg:my-zone:net> set physical=e1000g0
    zonecfg:my-zone:net> end
    
  9. Commit the configuration and exit.


    zonecfg:my-zone> commit
    zonecfg:my-zone> exit
    
  10. Attach the zone on the new host using one of the following methods.

    • Attach the zone with a validation check.


      host2# zoneadm -z my-zone attach
      

      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 -b 123456-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 – 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.


ProcedureHow 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.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Move the zonepath to the new host. You can use the method described in this procedure, or use another method of your choice.


Example 22–1 Archiving and Moving the zonepath Using the tar Command

  1. Create a tar file of the zonepath on host1 and transfer it to host2 by using the sftp command.


    host1# cd /export/zones
    host1# tar cf my-zone.tar my-zone
    host1# sftp host2
    Connecting to host2...
    Password:
    sftp> cd /export/zones
    sftp> put my-zone.tar
    Uploading my-zone.tar to /export/zones/my-zone.tar
    sftp> quit
    
  2. On host2, unpack the tar file.


    host2# cd /export/zones
    host2# tar xf my-zone.tar
    

For more information, see sftp(1) and tar(1).


Troubleshooting

See Resolving Problems With a zoneadm attach Operation for troubleshooting information on the following:

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 zoneadm uninstall 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 zoneadm detach 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 zoneadm attach 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.

ProcedureHow to Validate a Zone Migration Before the Migration Is Performed

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Use one of the following methods.

    • Generate the manifest on a source host named my-zone and pipe the output to a remote command that will immediately validate the target host:


      global# zoneadm -z my-zone detach -n | ssh remotehost zoneadm attach -n -
      

      The hyphen () at the end of the line specifies stdin for the path.

    • Generate the manifest on a source host named my-zone and direct the output to a file:


      global# zoneadm -z my-zone detach -n 
      

      Copy the manifest to the new host system as described in How to Move the zonepath to a new Host, and perform the validation:


      global# zoneadm attach -n path_to_manifest
      

      The path can be to specify stdin.

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.

The procedure for this task is described in steps 4 through 8 of How to Migrate A Non-Global Zone. Also see How to Move the zonepath to a new Host.

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.

To begin, examine the source system and collect needed information.

Creating the Image for Directly Migrating A Solaris System Into a Zone

You can use the Flash Archiving tools to create an image of an installed system that can be migrated into a zone.

The image can be fully configured with all of the software that will be run in the zone. This image is used by the installer when the zone is installed.

ProcedureHow to Use flarcreate to Create the Image

Use this process to create the system image. This example procedure uses NFS to place the flash archive on the target Solaris system, but you could use any method to move the files.

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

  1. Become superuser, or assume the Primary Administrator role.

  2. Log into the source system to be archived.

  3. Change directories to the root directory.


    # cd /
    
  4. Use flarcreate to create a flash archive image file named s-system, and place the archive onto the target system:


    target-system # flarcreate -S -n s-system /net/target/export/s-system.flar
    Determining which filesystems will be included in the archive...
    Creating the archive...
    cpio: File size of "etc/mnttab" has
    increased by 435
    2068650 blocks
    1 error(s)
    Archive creation complete.

    Tip –

    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:

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.

For more information, see the cpio(1), pax(1), bzip2(1), gzip(1), and ufsdump(1M) man pages.

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.

For more information about host IDs, see hostid(1).

Configure the Source Zone

Create the new zone configuration on the target system by using the procedure How to Configure the Zone.


Tip –

If you know you will be using CDs or DVDs to install applications in the new zone, use add fs 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.

You can use an image of a Solaris system that has been fully configured with all of the software that will be run in the zone. See Creating the Image for Directly Migrating A Solaris System Into a Zone.

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 – 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.

-d path

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.

ProcedureHow to Install the Zone

  1. Become superuser, or assume the Primary Administrator role.

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


    global# zoneadm -z s-zone install -u -a /net/machine_name/s-system.flar
    

    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

ProcedureHow to Boot the Zone

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

  1. Become superuser, or assume the Primary Administrator role.

  2. 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
    
  3. 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.

This chapter covers the following SVR4 packaging topics:

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

See OpenSolaris 2009.06 Image Packaging System Guide for more information.

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:


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:

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

If a package is currently installed in the global zone and currently installed in only a subset of the 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:

Package Operations Possible in a Non-Global Zone

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

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 -z zonename install 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 zoneadm halt, 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.

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:

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 following steps are performed by the pkgadd utility:

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:

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

  2. 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 following steps are performed by the pkgadd utility:

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.

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:

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:

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:

The following steps are performed by the pkgrm utility:

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:

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.

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:

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:

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:

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 following steps are performed by the patchadd utility:

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.

For more information about the database, see the pkgadm(1M) man page.

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).

To learn about IPS packaging on an OpenSolaris 2009.06 system, see OpenSolaris 2009.06 Image Packaging System Guide.

Adding and Removing Packages and Patches on a Solaris System With Zones Installed (Task Map)

Applicable to SVR4 only:

Task 

Description 

For Instructions 

Add a package. 

Add a package on a system with zones installed. 

Adding a Package on a Solaris System With Zones Installed

Check package information. 

Check package information on a system with zones installed. 

Checking Package Information on a Solaris System With Zones Installed

Remove a package. 

Remove a package on a system with zones installed. 

Removing a Package From a Solaris System With Zones Installed

Apply a patch. 

Apply a patch on a system with zones installed. 

Applying a Patch to a Solaris System With Zones Installed

Remove a patch. 

Remove a patch on a system with zones installed. 

Removing a Patch on a System with Zones Installed

(Optional) Check the package parameter settings. 

When adding or removing packages, verify that the settings of the package parameters support the action you want to perform. 

Checking Package Parameter Settings on a System with Zones Installed

Adding a Package on a Solaris System With Zones Installed

You can use the pkgadd system utility described in the pkgadd(1M) man page to perform the following tasks:

The SUNW_PKG_ALLZONES and SUNW_PKG_HOLLOW package parameter settings must match the correct value, either true or false, to add packages. Otherwise, the desired result will not be achieved. For more information about the effect of these package parameter settings, see About SVR4 Packages and Zones. For more information about how to check these package parameter settings, see Checking Package Parameter Settings on a System with Zones Installed.

ProcedureHow to Add a Package to the Global Zone Only

To add a package to the global zone only, the SUNW_PKG_ALLZONES package parameter must be set to false.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. While in the global zone, run the pkgadd -d command followed by the location of the package, the -G option, and then the package name.

    • If installing the package from a CD-ROM, type:


      global# pkgadd -d /cdrom/cdrom0/directory -G package_name
      
    • If installing the package from a directory to which it has been copied, type:


      global# pkgadd -d disk1/image -G package_name
      

      where disk1 is the location where the package was copied.


    Note –

    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.


ProcedureHow to Add a Package to the Global Zone and All Non-Global Zones

Do not use pkgadd option -G in this procedure.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. While in the global zone, run the pkgadd -d command followed by the location of the package and then the package name.

    • If installing the package from a CD-ROM, type:


      global# pkgadd -d /cdrom/cdrom0/directory package_name
      
    • If installing the package from a directory to which it has been copied, type:


      global# pkgadd -d disk1/image package_name
      

      where disk1 is the location where the package was copied.

ProcedureHow to Add a Package That Is Installed in the Global Zone to All Non-Global Zones

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

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

  3. Add the package without using the -G option.

ProcedureHow to Add a Package to a Specified Non-Global Zone Only

To add a package to a specified non-global zone only, the SUNW_PKG_ALLZONES package parameter must be set to false. Do not use the pkgadd option -G in this procedure or the operation fails.

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

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

  2. While in the non-global zone, my-zone in this procedure, run the pkgadd -d command followed by the location of the package and then the package name.

    • If installing the package from a CD-ROM, type:


      my-zone# pkgadd -d /cdrom/cdrom0/directory package_name
      
    • If installing the package from a directory to which it has been copied, type:


      my-zone# pkgadd -d disk1/image package_name
      

      where disk1 is the location where the package was copied.

Checking Package Information on a Solaris System With Zones Installed

You can query the software package database for the global zone and non-global zones by using the pkginfo command. See the pkginfo(1) man page for more information about this command.

ProcedureHow to Check Package Information in the Global Zone Only

  1. To check the software package database for the global zone only, use pkginfo followed by the package name.


    global% pkginfo package_name
    

Example 25–1 Using the pkginfo Command in the Global Zone


global% pkginfo SUNWcsr SUNWcsu
system      SUNWcsr Core Solaris, (Root)
system      SUNWcsu Core Solaris, (Usr)

ProcedureHow to Check Package Information in a Specified Non-Global Zone Only

  1. To check the software package database in a specific non-global zone, log into the non-global zone and use pkginfo followed by the package name.


    my-zone% pkginfo package_name
    

Example 25–2 Using the pkginfo Command in a Non-Global Zone


my-zone% pkginfo SUNWcsr SUNWcsu
system      SUNWcsr Core Solaris, (Root)
system      SUNWcsu Core Solaris, (Usr)

Removing a Package From a Solaris System With Zones Installed

You can use the pkgrm system utility described in the pkgrm(1M) man page to perform the following tasks:

The SUNW_PKG_ALLZONES and SUNW_PKG_HOLLOW package parameter settings must match the correct value, either true or false, to remove packages. Otherwise, the desired result will not be achieved. For more information about the effect of these package parameter settings, see About SVR4 Packages and Zones. For more information about how to check these package parameter settings, see Checking Package Parameter Settings on a System with Zones Installed.

ProcedureHow to Remove a Package From the Global Zone and All Non-Global Zones

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. While in the global zone, run the pkgrm command followed by the package name.


    global# pkgrm package_name
    

ProcedureHow to Remove a Package From a Specified Non-Global Zone Only

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

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

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

  2. While in the non-global zone, my-zone in this procedure, run the pkgrm command followed by the package name.


    my-zone# pkgrm package_name
    

Applying a Patch to a Solaris System With Zones Installed

You can use the patchadd system utility described in the patchadd(1M) man page to perform the following tasks:

ProcedureHow to Apply a Patch to the Global Zone Only

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Execute the patchadd command with the -Goption, followed by the patch ID.


    global# patchadd -G patch_id
    

ProcedureHow to Apply a Patch to the Global Zone and All Non-Global Zones

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Execute the patchadd command followed by the patch ID.


    global# patchadd patch_id
    

ProcedureHow to Apply a Patch to a Specified Non-Global Zone Only

To apply a patch to 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.

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

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


    my-zone# patchadd patch_id
    

Removing a Patch on a System with Zones Installed

You can use the patchrm system utility described in the patchrm(1M) man page to perform the following task:

ProcedureHow to Remove a Patch From the Global Zone and All Non-Global Zones

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Execute the patchrm command followed by the patch ID.


    global# patchrm patch_id
    

ProcedureHow 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.

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

  2. 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.

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

  1. 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.


    my-zone% pkgparam package_name SUNW_PKG_ALLZONES
    true
    my-zone% pkgparam package_name SUNW_PKG_HOLLOW
    false

Procedure(Optional) How to Check the Setting of a Package in Software on a CD-ROM

  1. To check the package parameter setting of an uninstalled package in software located on a CD-ROM, use pkgparam -d with the path of the CD-ROM followed by the package name and the name of the parameter.


    my-zone% pkgparam -d /cdrom/cdrom0/directory package_name SUNW_PKG_ALLZONES
    true
    my-zone% pkgparam -d /cdrom/cdrom0/directory package_name SUNW_PKG_HOLLOW 
    false 

Chapter 26 Solaris Zones Administration (Overview)

This chapter covers these general zone administration topics:

For information on lx branded zones, see Part III, Linux Branded Zones.

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:

For more information, see the ps(1) man page.

A -z zonename option has been added to the following Solaris utilities. You can use this option to filter the information to include only the zone or zones specified.

See Table 26–5 for the full list of changes made to commands.

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 -o nosuid Option

The -o nosuid option to the mount utility has the following functionality:

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 -o nosuid 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.

Options for mounting file systems in non-global zones are described in the following table. Procedures for these mounting alternatives are provided in Configuring, Verifying, and Committing a Zone and Mounting File Systems in Running Non-Global Zones.

Any file system type not listed in the table can be specified in the configuration if it has a mount binary in /usr/lib/fstype/mount.

File System 

Mounting Options in a Non-Global Zone 

AutoFS 

Cannot be mounted using zonecfg, cannot be manually mounted from the global zone into a non-global zone. Can be mounted from within the zone.

CacheFS 

Cannot be used in a non-global zone. 

FDFS 

Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone.

HSFS 

Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone.

LOFS 

Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone.

MNTFS 

Cannot be mounted using zonecfg, cannot be manually mounted from the global zone into a non-global zone. Can be mounted from within the zone.

NFS 

Cannot be mounted using zonecfg. V2, V3, and V4, which are the versions currently supported in zones, can be mounted from within the zone.

PCFS  

Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone.

PROCFS 

Cannot be mounted using zonecfg, cannot be manually mounted from the global zone into a non-global zone. Can be mounted from within the zone.

TMPFS 

Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone.

UDFS 

Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone.

UFS 

Can be mounted using zonecfg, can be manually mounted from the global zone into a non-global zone, can be mounted from within the zone.

XMEMFS 

Support for this file system has been removed from Solaris with this release. 

ZFS 

Can be mounted using the zonecfg dataset and fs resource types.

For more information, see How to Configure the Zone, Mounting File Systems in Running Non-Global Zones, and the mount(1M) man page.

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.

For more information, see The zoneadmd Daemon and the fsck(1M)

ZFS

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 add fs subcommand. The global administrator is responsible for setting and controlling the properties of the dataset.

For more information on ZFS, see Chapter 10, ZFS Advanced Topics, in Solaris ZFS Administration Guide.

Non-Global Zones as NFS Clients

Zones can be NFS clients. Version 2, version 3, and version 4 protocols are supported. For information on these NFS versions, see Features of the NFS Service in System Administration Guide: Network Services. .

The default version is NFS version 4. You can enable other NFS versions on a client by using one of the following methods:

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:

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:

An example is the -R root_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:

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

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:

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.

For more information, see the ifconfig(1M) and if_tcp(7P) man pages.

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:

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.

Solaris IP Filter can be enabled in non-global zones by turning on loopback filtering as described in Chapter 26, Solaris IP Filter (Tasks), in System Administration Guide: IP Services.

Solaris IP Filter is derived from open source IP Filter software.

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.

See How to Extend IP Network Multipathing Functionality to Shared-IP Non-Global Zones. The zones configuration procedure is covered in How to Configure the Zone. For information on IPMP features, components, and usage, see Chapter 12, Introducing IPMP, in System Administration Guide: Network Interfaces and Network Virtualization.

Networking in Exclusive-IP Non-Global Zones

An exclusive-IP zone has its own IP-related state and tuning variables. The zone is assigned its own set of data-links when the zone is configured.

For information on features that can be used in an exclusive-IP non-global zone, see Exclusive-IP Non-Global Zones. For information on tuning IP ndd variables, see Solaris Tunable Parameters Reference Manual.

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 dladm show-link command can be used to display data-links assigned to running zones.

For more information, see dladm(1M)

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 – 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:

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:

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:

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.

To assign zone shares by using the zonecfg command, see How to Set zone.cpu-shares in the Global Zone. For more information on project.cpu-shares, see Available Resource Controls. Also see Using the Fair Share Scheduler on a Solaris System With Zones Installed for example procedures that show how to set shares on a temporary basis.

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.

For information about IPQoS flow accounting, see Chapter 31, Using Flow Accounting and Statistics Gathering (Tasks), in System Administration Guide: IP Services.

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.

Table 26–1 Status of Privileges in Zones

Privilege 

Status 

Notes 

cpc_cpu

Optional 

Access to certain cpc(3CPC) counters

dtrace_proc

Optional 

fasttrap and pid providers; plockstat(1M)

dtrace_user

Optional 

profile and syscall providers

graphics_access

Optional 

ioctl(2) access to agpgart_io(7I)

graphics_map

Optional 

mmap(2) access to agpgart_io(7I)

net_rawaccess

Optional in shared-IP zones. 

Default in exclusive-IP zones. 

Raw PF_INET/PF_INET6 packet access

proc_clock_highres

Optional 

Use of high resolution timers 

proc_priocntl

Optional 

Scheduling control; priocntl(1)

sys_ipc_config

Optional 

Raising IPC message queue buffer size 

sys_time

Optional 

System time manipulation; xntp(1M)

dtrace_kernel

Prohibited 

Currently unsupported 

proc_zone

Prohibited 

Currently unsupported 

sys_config

Prohibited 

Currently unsupported 

sys_devices

Prohibited 

Currently unsupported 

sys_linkdir

Prohibited 

Currently unsupported 

sys_net_config

Prohibited 

Currently unsupported 

sys_res_config

Prohibited 

Currently unsupported 

sys_suser_compat

Prohibited 

Currently unsupported 

proc_exec

Required, Default 

Used to start init(1M)

proc_fork

Required, Default 

Used to start init(1M)

sys_mount

Required, Default 

Needed to mount required file systems 

sys_ip_config

Required, Default in exclusive-IP zones 

Prohibited in shared-IP zones 

Required to boot zone and initialize IP networking in exclusive-IP zone 

contract_event

Default 

Used by contract file system 

contract_observer

Default 

Contract observation regardless of UID 

file_chown

Default 

File ownership changes 

file_chown_self

Default 

Owner/group changes for own files 

file_dac_execute

Default 

Execute access regardless of mode/ACL 

file_dac_read

Default 

Read access regardless of mode/ACL 

file_dac_search

Default 

Search access regardless of mode/ACL 

file_dac_write

Default 

Write access regardless of mode/ACL 

file_link_any

Default 

Link access regardless of owner 

file_owner

Default 

Other access regardless of owner 

file_setid

Default 

Permission changes for setid, setgid, setuid files

ipc_dac_read

Default 

IPC read access regardless of mode 

ipc_dac_owner

Default 

IPC write access regardless of mode 

ipc_owner

Default 

IPC other access regardless of mode 

net_icmpaccess

Default 

ICMP packet access: ping(1M)

net_privaddr

Default 

Binding to privileged ports 

proc_audit

Default 

Generation of audit records 

proc_chroot

Default 

Changing of root directory

proc_info

Default 

Process examination 

proc_lock_memory

Default 

Locking memory; shmctl(2)and mlock(3C)

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 

win_dac_read

Optional 

Read from window resource not owned by client's user ID 

win_dac_write

Optional 

Write to or create window resource not owned by client's user ID 

win_devices

Optional 

Perform operations on input devices. 

win_dga

Optional 

Use direct graphics access X protocol extensions; frame buffer privileges needed 

win_downgrade_sl

Optional 

Change sensitivity label of window resource to new label dominated by existing label 

win_fontpath

Optional 

Add an additional font path 

win_mac_read

Optional 

Read from window resource with a label that dominates the client's label 

win_mac_write

Optional 

Write to window resource with a label not equal to the client's label 

win_selection

Optional 

Request data moves without confirmer intervention 

win_upgrade_sl

Optional 

Change sensitivity label of window resource to a new label not dominated by existing label 

net_bindmlp

Default 

Allows binding to a multilevel port (MLP) 

net_mac_aware

Default 

Allows reading down through NFS 

To alter privileges in a non-global zone configuration, see Configuring, Verifying, and Committing a Zone

To inspect privilege sets, see Using the ppriv Utility. For more information about privileges, see the ppriv(1) man page and System Administration Guide: Security Services.

Using IP Security Architecture in Zones

The Internet Protocol Security Architecture (IPsec), which provides IP datagram protection, is described in Chapter 19, IP Security Architecture (Overview), in System Administration Guide: IP Services. The Internet Key Exchange (IKE) protocol is used to manage the required keying material for authentication and encryption automatically.

For more information, see the ipsecconf(1M) and ipseckey(1M) man pages.

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.

IP Security Architecture in Exclusive-IP Zones

IPsec can be used in exclusive-IP zones.

Using Solaris Auditing in Zones

Solaris auditing is described in Chapter 28, Solaris Auditing (Overview), in System Administration Guide: Security Services. For zones considerations associated with auditing, see the following sections:

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:

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.

For additional information, see the audit_control(4) and audit_user(4) man pages.

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.

For more information, see the audit_startup(1M) and auditreduce(1M) man pages.

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.

For more information, see the coreadm(1M) and core(4) man pages.

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 zonecfg limitpriv 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.

Also see Privileges in a Non-Global Zone for more information.

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 – 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:

Backing Up Individual Non-Global Zones on Your System

You might decide to perform backups within the non-global zones in the following cases.

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:

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:

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:

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:

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.

Table 26–3 Commands Used to Administer Zones

Command Reference 

Description 

zlogin(1)

Log in to a non-global zone 

zonename(1)

Prints the name of the current zone 

zoneadm(1M)

Administers zones on a system 

zonecfg(1M)

Used to set up a zone configuration 

getzoneid(3C)

Used to map between zone ID and name 

zones(5)

Provides description of zones facility 

zcons(7D)

Zone console device driver 

The zoneadmd daemon is the primary process for managing the zone's virtual platform. The man page for the zoneadmd daemon is zoneadmd(1M). The daemon does not constitute a programming interface.

The commands in the next table are used with the resource capping daemon.

Table 26–4 Commands Used With rcapd

Command Reference 

Description 

rcapstat(1)

Monitors the resource utilization of capped projects. 

rcapadm(1M)

Configures the resource capping daemon, displays the current status of the resource capping daemon if it has been configured, and enables or disables resource capping 

rcapd(1M)

The resource capping daemon. 

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

Command Reference 

Description 

ipcrm(1)

Added -z zone option. This option is only useful when the command is executed in the global zone.

ipcs(1)

Added -z zone option. This option is only useful when the command is executed in the global zone.

pgrep(1)

Added -z zoneidlist option. This option is only useful when the command is executed in the global zone.

ppriv(1)

Added the expression zone for use with the -l option to list all privileges available in the current zone. Also use the option -v after zone to obtain verbose output.

priocntl(1)

Zone ID can be used in idlist and -i idtype to specify processes. You can use the priocntl -i zoneid command to move running processes into a different scheduling class in a non-global zone.

proc(1)

Added -z zone option to ptree only. This option is only useful when the command is executed in the global zone.

ps(1)

Added zonename and zoneid to list of recognized format names used with the -o option.

Added -z zonelist 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.

Added -Z to print the name of the zone associated with the process. The name is printed under an additional column header, ZONE.

renice(1)

Added zoneid to list of valid arguments used with the -i option.

sar(1)

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.

auditconfig(1M)

Added zonename token.

auditreduce(1M)

Added -z zone-name option. Added ability to get an audit log of a zone.

coreadm(1M)

Added variable %z to identify the zone in which process executed.

df(1M)

Added -Z option to display mounts in all visible zones. This option has no effect in a non-global zone.

ifconfig(1M)

Added zone option for global zone use (the default), and -zone zonename for non-global zone use.

iostat(1M)

If executed in a non-global zone in which the pools facility is enabled, information is provided only for those processors that are in the processor set of the pool to which the zone is bound. 

kstat(1M)

If executed in the global zone, kstats are displayed for all zones. If executed in a non-global zone, only kstats with a matching zoneid are displayed.

mpstat(1M)

If executed in a non-global zone in which the pools facility is enabled, command only displays lines for the processors that are in the processor set of the pool to which the zone is bound. 

ndd(1M)

When used in the global zone, displays information for all zones. ndd on the TCP/IP modules in an exclusive-IP zone only displays information for that zone.

netstat(1M)

Displays information for the current zone only. 

nfsstat(1M)

Displays statistics for the current zone only. 

poolbind(1M)

Added zoneid list. Also see Resource Pools Used in Zones for information about using zones with resource pools.

prstat(1M)

Added -z zoneidlist option. Also added -Z option.

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.

psrinfo(1M)

If executed in a non-global zone, only information about the processors visible to the zone is displayed. 

traceroute(1M)

Usage change. When specified from within a non-global zone, the -F option has no effect because the “don't fragment” bit is always set.

vmstat(1M)

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.

auditon(2)

Added AUDIT_ZONENAME to generate a zone ID token with each audit record.

priocntl(2)

Added P_ZONEID id argument.

processor_info(2)

If the caller is in a non-global zone and the pools facility is enabled, but the processor is not in the processor set of the pool to which the zone is bound, an error is returned. 

p_online(2)

If the caller is in a non-global zone and the pools facility is enabled, but the processor is not in the processor set of the pool to which the zone is bound, an error is returned. 

pset_bind(2)

Added P_ZONEID as idtype. Added zone to possible choices for P_MYID specification. Added P_ZONEID to valid idtype list in EINVAL error description.

pset_info(2)

If the caller is in a non-global zone and the pools facility is enabled, but the processor is not in the processor set of the pool to which the zone is bound, an error is returned. 

pset_list(2)

If the caller is in a non-global zone and the pools facility is enabled, but the processor is not in the processor set of the pool to which the zone is bound, an error is returned. 

pset_setattr(2)

If the caller is in a non-global zone and the pools facility is enabled, but the processor is not in the processor set of the pool to which the zone is bound, an error is returned. 

sysinfo(2)

Changed PRIV_SYS_CONFIG to PRIV_SYS_ADMIN.

umount(2)

ENOENT is returned if file pointed to by file is not an absolute path.

getloadavg(3C)

If the caller is in a non-global zone and the pools facility is enabled, the behavior is equivalent to calling with a psetid of PS_MYID.

getpriority(3C)

Added zone IDs to target processes that can be specified. Added zone ID to EINVAL error description.

priv_str_to_set(3C)

Added “zone” string for the set of all privileges available within the caller's zone. 

pset_getloadavg(3C)

If the caller is in a non-global zone and the pools facility is enabled, but the processor is not in the processor set of the pool to which the zone is bound, an error is returned. 

sysconf(3C)

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.

ucred_get(3C)

Added ucred_getzoneid() function, which returns the zone ID of the process or -1 if the zone ID is not available.

core(4)

Added n_type: NT_ZONENAME. This entry contains a string that describes the name of the zone in which the process was running.

pkginfo(4)

Now provides optional parameters and an environment variable in support of zones. 

proc(4)

Added capability to obtain information on processes running in zones. 

audit_syslog(5)

Added in<zone name> field that is used if the zonename audit policy is set.

privileges(5)

Added PRIV_PROC_ZONE, which allows a process to trace or send signals to processes in other zones. See zones(5).

if_tcp(7P)

Added zone ioctl() calls.

cmn_err(9F)

Added zone parameter. 

ddi_cred(9F)

Added crgetzoneid(), which returns the zone ID from the user credential pointed to by cr.

Chapter 27 Administering Solaris Zones (Tasks)

This chapter covers general administration tasks and provides usage examples.

See Chapter 26, Solaris Zones Administration (Overview) for general zone administration topics.

Using the ppriv Utility

Use the ppriv utility to display the zone's privileges.

ProcedureHow to List Solaris Privileges in the Global Zone

Use the ppriv utility with the -l option to list the privileges available on the system.

  1. At the prompt, type ppriv -l zone 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
    .
    .
    .

ProcedureHow 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.

  1. Log into the non-global zone. This example uses a zone named my-zone.

  2. At the prompt, type ppriv -l zone 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
    
    .
    .
    .

ProcedureHow 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.

  1. Log into the non-global zone. This example uses a zone named my-zone.

  2. At the prompt, type ppriv -l -v zone 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.
    .
    .
    .

Using DTrace in a Non-Global Zone

Perform the following steps to use DTrace functionality as described in Running DTrace in a Non-Global Zone.

ProcedureHow to Use DTrace

  1. Use the zonecfg limitpriv property to add the dtrace_proc and dtrace_user privileges.


    global# zonecfg -z my-zone
    zonecfg:my-zone> set limitpriv="default,dtrace_proc,dtrace_user"
    zonecfg:my-zone> exit
    

    Note –

    Depending on your requirements, you can add either privilege, or both privileges.


  2. Boot the zone.


    global# zoneadm -z my-zone boot
    
  3. Log in to the zone.


    global# zlogin my-zone
    
  4. Run the DTrace program.


    my-zone# dtrace -l
    

Checking the Status of SMF Services in a Non-Global Zone

To check the status of SMF services in a native non-global zone, use the zlogin command.

ProcedureHow to Check the Status of SMF Services From the Command Line

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. From the command line, type the following to show all services, including disabled ones.


    global# zlogin my-zone svcs -a
    
See Also

For more information, see Chapter 21, Logging In to Non-Global Zones (Tasks) and svcs(1).

ProcedureHow to Check the Status of SMF Services From Within a Zone

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Log in to the zone.


    global# zlogin my-zone
    
  3. Run the svcs command with the -a option to show all services, including disabled ones.


    my-zone# svcs -a
    
See Also

For more information, see Chapter 21, Logging In to Non-Global Zones (Tasks) and svcs(1).

Mounting File Systems in Running Non-Global Zones

You can mount file systems in a running non-global zone. The following procedures are covered.

ProcedureSX 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.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Change directories to /usr/tmp.


    global# cd /usr/tmp
    
  3. Create a new UFS file system.


    global# mkfile 10m fsfile
    
  4. Attach the file as a block device.

    The first available slot, which is /dev/lofi/1 if no other lofi devices have been created, is used.


    global# lofiadm -a `pwd`/fsfile
    

    You will also get the required character device.

  5. Import the devices into the zone my-zone.


    global# zonecfg -z my-zone
    zonecfg:my-zone> add device
    zonecfg:my-zone:device> set match=/dev/rlofi/1
    zonecfg:my-zone:device> end
    zonecfg:my-zone> add device
    zonecfg:my-zone:device> set match=/dev/lofi/1
    zonecfg:my-zone:device> end
    
  6. Reboot the zone.


    global# zoneadm -z my-zone boot
    
  7. Log in to the zone and verify that the devices were successfully imported.


    my-zone# ls  -l /dev/*lofi/*
    

    You will see a display that is similar to this:


    brw-------   1 root     sys      147,  1 Jan  7 11:26 /dev/lofi/1
    crw-------   1 root     sys      147,  1 Jan  7 11:26 /dev/rlofi/1
See Also

For more information, see the lofiadm(1M) and lofi(7D) man pages.

ProcedureHow to Mount the File System Manually

You must be the zone administrator and have the Zone Management profile to perform this procedure. This procedure uses the newfs command, which is described in the newfs(1M) man page.

  1. Become superuser, or have the Zone Management rights profile in your list of profiles.

  2. In the zone my-zone, create a new file system on the disk.


    my-zone# newfs /dev/lofi/1
    
  3. Respond yes at the prompt.


    newfs: construct a new file system /dev/rlofi/1: (y/n)? y
    

    You will see a display that is similar to this:


    /dev/rlofi/1:   20468 sectors in 34 cylinders of 1 tracks, 602 sectors
            10.0MB in 3 cyl groups (16 c/g, 4.70MB/g, 2240 i/g)
    super-block backups (for fsck -F ufs -o b=#) at:
     32, 9664, 19296,
  4. Check the file system for errors.


    my-zone# fsck -F ufs /dev/rlofi/1
    

    You will see a display that is similar to this:


    ** /dev/rlofi/1
    ** Last Mounted on 
    ** Phase 1 - Check Blocks and Sizes
    ** Phase 2 - Check Pathnames
    ** Phase 3 - Check Connectivity
    ** Phase 4 - Check Reference Counts
    ** Phase 5 - Check Cyl groups
    2 files, 9 used, 9320 free (16 frags, 1163 blocks, 0.2% fragmentation)
  5. Mount the file system.


    my-zone# mount -F ufs /dev/lofi/1 /mnt
    
  6. Verify the mount.


    my-zone# grep /mnt /etc/mnttab
    

    You will see a display similar to this:


    /dev/lofi/1     /mnt    ufs
    rw,suid,intr,largefiles,xattr,onerror=panic,zone=foo,dev=24c0001
    1073503869

ProcedureHow to Place a File System in /etc/vfstab to Be Mounted When the Zone Boots

This procedure is used to mount the block device /dev/lofi/1 on the file system path /mnt. The block device contains a UFS file system. The following options are used:

  1. Become superuser, or have the Zone Management rights profile in your list of profiles.

  2. In the zone my-zone, add the following line to /etc/vfstab:


    /dev/lofi/1 /dev/rlofi/1  /mnt   ufs  2  yes logging

ProcedureHow to Mount a File System From the Global Zone Into a Non-Global Zone

Assume that a zone has the zonepath /export/home/my-zone. You want to mount the disk /dev/lofi/1 from the global zone into /mnt in the non-global zone.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. To mount the disk into /mnt in the non-global zone, type the following from the global zone:


    global# mount -F ufs /dev/lofi/1 /export/home/my-zone/root/mnt
    
See Also

For information about lofi, see the lofiadm(1M) and lofi(7D) man pages.

Adding Non-Global Zone Access to Specific File Systems in the Global Zone

ProcedureHow 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.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Determine whether the Volume Management file system is running in the global zone.


    global# svcs volfs
    STATE          STIME    FMRI
    online         Sep_29   svc:/system/filesystem/volfs:default
  3. (Optional) If the Volume Management file system is not running in the global zone, start it.


    global# svcadm volfs enable
    
  4. Insert the media.

  5. Check for media in the drive.


    global# volcheck
    
  6. Test whether the DVD is automounted.


    global# ls /cdrom
    

    You will see a display similar to the following:


    cdrom   cdrom1   jes_05q4_dvd
  7. Loopback mount the file system with the options ro,nodevices (read-only and no devices) in the non-global zone.


    global# zonecfg -z my-zone
    zonecfg:my-zone> add fs
    zonecfg:my-zone:fs> set dir=/cdrom
    zonecfg:my-zone:fs> set special=/cdrom
    zonecfg:my-zone:fs> set type=lofs
    zonecfg:my-zone:fs> add options [ro,nodevices]
    zonecfg:my-zone:fs> end
    zonecfg:my-zone> commit
    zonecfg:my-zone> exit
    
  8. Reboot the non-global zone.


    global# zoneadm -z my-zone reboot
    
  9. Use the zoneadm list command with the -v option to verify the status.


    global# zoneadm list -v
    

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


    ID  NAME     STATUS       PATH                           BRAND      IP
     0  global   running      /                              native     shared
     1  my-zone  running      /export/home/my-zone           native     shared
  10. Log in to the non-global zone.


    global# zlogin my-zone
    
  11. Verify the DVD-ROM mount.


    my-zone# ls /cdrom
    

    You will see a display similar to this:


    cdrom   cdrom1   jes_05q4_dvd
  12. Install the product as described in the product installation guide.

  13. Exit the non-global zone.


    my-zone# exit
    

    Tip –

    You might want to retain the /cdrom file system in your non-global zone. The mount will always reflect the current contents of the CD-ROM drive, or an empty directory if the drive is empty.


  14. (Optional) If you want to remove the /cdrom file system from the non-global zone, use the following procedure.


    global# zonecfg -z my-zone
    zonecfg:my-zone> remove fs dir=/cdrom
    zonecfg:my-zone> commit
    zonecfg:my-zone> exit
    

ProcedureHow to Add a Writable Directory under /usr in a Non-Global Zone

In a native sparse root zone, /usr is mounted read-only from the global zone. You can use this procedure to add a writable directory, such as /usr/local, under /usr in your zone.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Create the directory /usr/local in the global zone.


    global# mkdir -p /usr/local
    
  3. Specify a directory in the global zone to serve as the backing store for the zone's /usr/local directory.


    global# mkdir -p /storage/local/my-zone
    
  4. Edit the configuration for the zone my-zone.


    global# zonecfg -z my-zone
    
  5. Add the loopback-mounted filesystem.


    zonecfg:my-zone> add fs
    zonecfg:my-zone:fs> set dir=/usr/local
            zonecfg:my-zone:fs> set special=/storage/local/my-zone
            zonecfg:my-zone:fs> set type=lofs
            zonecfg:my-zone:fs> end
            zonecfg:my-zone> commit
            zonecfg:my-zone> exit
    
  6. Boot the zone.

ProcedureHow to Export Home Directories in the Global Zone Into a Non-Global Zone

This procedure is used to export home directories or other file systems from the global zone into non-global zones on the same system.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Add the loopback-mounted filesystem.


    global# zonecfg -z my-zone
    zonecfg:my-zone> add fs
    zonecfg:my-zone:fs> set dir=/export/home
    zonecfg:my-zone:fs> set special=/export/home
    zonecfg:my-zone:fs> set type=lofs
    zonecfg:my-zone:fs> set options=nodevices
    zonecfg:my-zone:fs> end
    zonecfg:my-zone> commit
    zonecfg:my-zone> exit
    
  3. Add the following line to the zone's /etc/auto_home file:


    $HOST:/export/home/&

Using IP Network Multipathing on a Solaris System With Zones Installed

ProcedureHow 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.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Configure IPMP groups as described in Configuring IPMP Groups in System Administration Guide: Network Interfaces and Network Virtualization.

ProcedureHow to Extend IP Network Multipathing Functionality to Shared-IP Non-Global Zones

Use this procedure to configure IPMP in the global zone and extend the IPMP functionality to non-global zones.

Each address, or logical interface, should be associated with a non-global zone when you configure the zone. See Using the zonecfg Command and How to Configure the Zone for instructions.

This procedure accomplishes the following:

In a running zone, you can use the ifconfig command to make the association. See Shared-IP Network Interfaces and the ifconfig(1M) man page.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. In the global zone, configure IPMP groups as described in Configuring IPMP Groups in System Administration Guide: Network Interfaces and Network Virtualization.

  3. Use the zonecfg command to configure the zone. When you configure the net resource, add address 192.168.0.1 and physical interface bge0 to the zone my-zone:


    zonecfg:my-zone> add net
    zonecfg:my-zone:net> set address=192.168.0.1
    zonecfg:my-zone:net> set physical=bge0
    zonecfg:my-zone:net> end
    

    Only bge0 would be visible in non-global zone my-zone.

If bge0 Subsequently Fails

If bge0 subsequently fails and the bge0 data addresses fail over to hme0 in the global zone, the my-zone addresses migrate as well.

If address 192.168.0.1 moves to hme0, then only hme0 would now be visible in non-global zone my-zone. This card would be associated with address 192.168.0.1, and bge0 would no longer be visible.

Administering Data-Links in Exclusive-IP Non-Global Zones

The dladm command is used from the global zone to administer data-links.

ProcedureHow to Use dladm show-linkprop

The dladm command can be used with the show-linkprop subcommand to show the assignment of data-links to running exclusive-IP zones.

You must be the global administrator in the global zone to administer data-links.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Show the assignment of data-links on the system.


    global# dladm show-linkprop
    

Example 27–1 Using dladm With the show-linkprop subcommand

  1. In the first screen, zone 49bge, which is assigned bge0 has not been booted


    global# dladm show-linkprop
    LINK         PROPERTY        VALUE          DEFAULT        POSSIBLE
    bge0         zone            --             --             --
    ath0         channel         6              --             --
    ath0         powermode       ?              off            off,fast,max
    ath0         radio           ?              on             on,off
    ath0         speed           11             -- 
    1,2,5.5,6,9,11,12,18,24,36,48,54
    ath0         zone            --             --             --
  2. Zone 49bge is booted.


    global# zoneadm -z 49bge boot
    
  3. The command dladm show-linkprop is run again. Note that the bge0 link is now assigned to 49bge.


    global# dladm show-linkprop
    LINK         PROPERTY        VALUE          DEFAULT        POSSIBLE
    bge0         zone            49bge          --             --
    ath0         channel         6              --             --
    ath0         powermode       ?              off            off,fast,max
    ath0         radio           ?              on             on,off
    ath0         speed           11             -- 
    1,2,5.5,6,9,11,12,18,24,36,48,54
    ath0         zone            --             --             --

ProcedureHow to Use dladm set-linkprop

The dladm command can be used with the set-linkprop subcommand to temporarily assign data-links to running exclusive-IP zones. Persistent assignment must be made through the zonecfg command.

You must be the global administrator in the global zone to administer data-links.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Use dladm set-linkprop with the -t to add bge0 to a running zone called excl.


    global# dladm set-linkprop -t -p zone=excl bge0
    LINK         PROPERTY        VALUE          DEFAULT        POSSIBLE
    bge0         zone            excl           --             --

    Tip –

    The -p option produces a display using a stable machine-parseable format.


ProcedureHow to Use dladm reset-linkprop

The dladm command can be used with the reset-linkprop subcommand to reset the bge0 link value to unassigned.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Use dladm reset-linkprop with the -t to undo the zone assignment of the bge0 device.


    global# dladm set-linkprop -t -p zone=excl bge0
    LINK         PROPERTY        VALUE          DEFAULT        POSSIBLE
    bge0         zone            excl           --             --

    Tip –

    The -p option produces a display using a stable machine-parseable format.


Troubleshooting

If the running zone is using the device, the reassignment fails and an error message is displayed. See Exclusive-IP Zone Is Using Device, so dladm reset-linkprop Fails.

Using the Fair Share Scheduler on a Solaris System With Zones Installed

Limits specified through the prctl command are not persistent. The limits are only in effect until the system is rebooted. To set shares in a zone permanently, see How to Configure the Zone and How to Set zone.cpu-shares in the Global Zone.

ProcedureHow 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.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Use the prctl utility to assign two shares to the global zone:


    # prctl -n zone.cpu-shares -v 2 -r -i zone global
    
  3. (Optional) To verify the number of shares assigned to the global zone, type:


    # prctl -n zone.cpu-shares -i zone global
    
See Also

For more information on the prctl utility, see the prctl(1) man page.

ProcedureHow to Change the zone.cpu-shares Value in a Zone Dynamically

This procedure can be used for any zone, not just the global zone.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration

  2. Use the prctl command to specify a new value for cpu-shares.


    # prctl  -n zone.cpu-shares -r -v value -i zone zonename
    

    idtype is either the zonename or the zoneid. value is the new value.

Using Rights Profiles in Zone Administration

This section covers tasks associated with using rights profiles in non-global zones.

ProcedureHow to Assign the Zone Management Profile

The Zone Management profile grants the power to manage all of the non-global zones on the system to a user.

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

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Create a role that includes the Zone Management rights profile, and assign the role to a user.

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.

ProcedureHow 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.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. (Optional) Shut down the zone to put the zone in a quiescent state and to avoid creating backups of shared file systems.


    global# zlogin -S my-zone init 0
    
  3. Check the zone's status.


    global# zoneadm list -cv
    

    You will see a display similar to the following:


    ID  NAME     STATUS       PATH                           BRAND      IP
     0  global   running      /                              native     shared
     -  my-zone  installed    /export/home/my-zone           native     shared
  4. Perform the backup.


    global# ufsdump 0f /backup/my-zone.ufsdump /export/my-zone
    

    You will see a display similar to the following:


    DUMP: Date of this level 0 dump: Wed Aug 10 16:13:52 2005
    DUMP: Date of last level 0 dump: the epoch
    DUMP: Dumping /dev/rdsk/c0t0d0s0 (bird:/) to /backup/my-zone.ufsdump. 
    DUMP: Mapping (Pass I) [regular files]
    DUMP: Mapping (Pass II) [directories]
    DUMP: Writing 63 Kilobyte records
    DUMP: Estimated 363468 blocks (174.47MB).
    DUMP: Dumping (Pass III) [directories]
    DUMP: Dumping (Pass IV) [regular files]
    DUMP: 369934 blocks (180.63MB) on 1 volume at 432 KB/sec
    DUMP: DUMP IS DONE
  5. Boot the zone.


    global# zoneadm -z my-zone boot
    

ProcedureHow 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:

Before You Begin

The destination backup is /backup/my-zone.ufs. You must create the directory backup under /.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Create the snapshot.


    global# fssnap -o bs=/export /export/home
    

    You will see a display similar to the following:


    dev/fssnap/0
  3. Mount the snapshot.


    global# mount -o ro /dev/fssnap/0 /mnt
    
  4. Back up my-zone from the snapshot.


    global# ufsdump 0f /backup/my-zone.ufsdump /mnt/my-zone
    

    You will see a display similar to the following:


    DUMP: Date of this level 0 dump: Thu Oct 06 15:13:07 2005
       DUMP: Date of last level 0 dump: the epoch
       DUMP: Dumping /dev/rfssnap/0 (pc2:/mnt) to /backup/my-zone.ufsdump.
       DUMP: Mapping (Pass I) [regular files]
       DUMP: Mapping (Pass II) [directories]
       DUMP: Writing 32 Kilobyte records
       DUMP: Estimated 176028 blocks (85.95MB).
       DUMP: Dumping (Pass III) [directories]
       DUMP: Dumping (Pass IV) [regular files]
       DUMP: 175614 blocks (85.75MB) on 1 volume at 2731 KB/sec
       DUMP: DUMP IS DONE
  5. Unmount the snapshot.


    global# umount /mnt
    
  6. Delete the snapshot.


    global# fssnap -d /dev/fssnap/0
    

    Note that the snapshot is also removed from the system when the system is rebooted.

ProcedureHow to Use find and cpio to Perform Backups

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Change directories to the root directory.


    global# cd /
    
  3. Back up my-zone files that are not loopback mounted to /backup/my-zone.cpio.


    global# find export/my-zone -fstype lofs -prune -o -local
     | cpio -oc -O /backup/my-zone.cpio type as one line
    
  4. Verify the results.


    global# ls -l backup/my-zone.cpio
    

    You will see a display similar to the following:


    -rwxr-xr-x   1 root     root     99680256 Aug 10 16:13 backup/my-zone.cpio

ProcedureHow 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.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. 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

ProcedureHow 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.

  1. Become superuser, or assume the Primary Administrator role.

    To create the role and assign the role to a user, see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

  2. Specify that my-zone.config be used as the zonecfg command file to recreate the zone my-zone.


    global# zonecfg -z my-zone -f my-zone.config
    
  3. Install the zone.


    global# zoneadm -z my-zone install
    
  4. To prevent the system from displaying the sysidtool questions upon initial zone login, delete the file zonepath/root/etc/.UNCONFIGURED, for example:


    global# rm /export/home/my-zone/root/etc/.UNCONFIGURED
    
  5. If you have any zone-specific files to restore, such as application data, manually restore (and possibly hand-merge) files from a backup into the newly created zone's root file system.

Chapter 28 Troubleshooting Miscellaneous Solaris Zones Problems

This chapter contains zones troubleshooting information.

Information on Zones in the OpenSolaris 2009.06 Release

See About Zones in the OpenSolaris 2009.06 Release.

Exclusive-IP Zone Is Using Device, so dladm reset-linkprop Fails

If the following error message is displayed:


dladm: warning: cannot reset link property 'zone' on 'bge0': operation failed

Referring to How to Use dladm reset-linkprop, the attempt to use dladm reset-linkprop failed. The running zone excl is using the device, which was assigned by executing ifconfig bge0 plumb inside the zone.

To reset the value, use the procedure ifconfig bge0 unplumb 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:


zonecfg:zone5> set limitpriv="basic"
.
.
.
global# zoneadm -z zone5 boot
 	required privilege "sys_mount" is missing from the zone's privilege set
 	zoneadm: zone zone5 failed to verify

Zone Administrator Mounting Over File Systems Populated by the Global Zone

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:


# zoneadm -z my-zone boot
zoneadm: zone 'my-zone': WARNING: hme0:1: no matching subnet
	found in netmasks(4) for 192.168.0.1; using default of
	255.255.255.0.

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 zoneadm halt will completely halt the zone.

Resolving Problems With a zoneadm attach Operation

ProcedurePatches 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.

  1. 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
  2. To migrate the zone successfully, use one of the following methods:

ProcedureOperating 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.

  1. Verify the Solaris release running on the original system.


    host1# uname -a
    
  2. Install the same release on the new host.

    Refer to the Solaris installation documentation on docs.sun.com.

ProcedureMachine Architectures Do Not Match

To migrate the zone successfully, use the -u option to zoneadm attach.

  1. Verify the system architecture on both systems.


    host1# uname -a
    
  2. If the architectures are different, use the -u option to zoneadm attach to perform the attach.


    host2# zoneadm -z my-zone attach -u
    

    For more information, see How to Migrate A Non-Global Zone.