test

System Administration Guide: Virtualization Using the Solaris Operating System

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.