sun.com docs.sun.com My Sun Worldwide Sites

Previous Previous     Contents     Index     Next Next

Chapter 18

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

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.

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.

See Determine the Zone Host Name and Obtain the Network Address 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 plumbed in the zone.

Review your application requirements.

See 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 Solaris Express release. The following primary machine considerations are associated with the use of zones.

  • The performance requirements of the applications running within each zone.

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

Disk Space Requirements

There are no limits on how much disk space can be consumed by a zone. The global administrator is responsible for space restriction. The global administrator must ensure that local storage is sufficient to hold a non-global zone's root file system. Even a small uniprocessor system can support a number of zones running simultaneously.

The nature of the packages installed in the global zone affects the space requirements of the non-global zones that are created. The number of packages and space requirements are factors.

Sparse Root Zones

Non-global zones that have inherit-pkg-dir resources are called sparse root zones.

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

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

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

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

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

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

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

Whole Root Zones

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

The disk requirements for this model are determined by the disk space used by the packages currently installed in the global zone.


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

  • /lib

  • /platform

  • /sbin

  • /usr

See How to Configure the Zone.


Restricting Zone Size

The following options can be used to restrict zone size:

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

  • You can use soft partitions to divide disk slices or logical volumes into partitions. You can use these partitions as zone roots, and thus limit per-zone disk consumption. The soft partition limit is 8192 partitions. For more information, see Chapter 12, "Soft Partitions (Overview)," in Solaris Volume Manager Administration Guide.

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

Previous Previous     Contents     Index     Next Next
Company Info Contact Terms of Use Privacy Copyright 1994-2007 Sun Microsystems, Inc.