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 20, Installing, Booting, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks).
For information about lx branded zone installation, see Chapter 34, About Installing, Booting, Halting, Cloning, and Uninstalling lx Branded Zones (Overview) and Chapter 35, Installing, Booting, Halting, Uninstalling and Cloning lx Branded Zones (Tasks).
Solaris 10 11/06: The ability to clone a non-global zone is now available. See Solaris 10 11/06: Cloning a Non-Global Zone on the Same System.
Solaris 10 8/07: Information on boot arguments has also been added. See Solaris 10 8/07: Zone Boot Arguments.
Solaris 10 5/09: ZFS clone has been implemented. 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. If both zonepaths are non-ZFS, or if one is ZFS and the other non-ZFS, the code will use the existing copy technique.
The zoneadm command described in the zoneadm(1M) man page is the primary tool used to install and administer non-global zones. Operations using the zoneadm command must be run from the global zone. The following tasks can be performed using the zoneadm command:
Verify a zone
Install a zone
Boot a zone, which is similar to booting a regular Solaris system
Display information about a running zone
Halt a zone
Reboot a zone
Uninstall a zone
Relocate a zone from one point on a system to another point on the same system
Provision a new zone based on the configuration of an existing zone on the same system
Migrate a zone, used with the zonecfg command
For zone installation and verification procedures, see Chapter 20, 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 18, 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.
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 open networking configuration (generic_open.xml). Network configuration types are described in Chapter 19, Managing Services (Tasks), in System Administration Guide: Basic Administration. The zone administrator can switch the zone to the limited networking configuration (generic_limited_net.xml) by using the netservices command. Specific services can be enabled or disabled by using SMF commands.
A successfully installed zone is ready for initial login and booting.
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.
Data from the following are not referenced or copied when a zone is installed:
Data on CDs and DVDs
Network installation images
Any prototype or other instance of a zone
In addition, the following types of information, if present in the global zone, are not copied into a zone that is being installed:
New or changed users in the /etc/passwd file
New or changed groups in the /etc/group file
Configurations for networking services such as DHCP address assignment, UUCP, or sendmail
Configurations for network services such as naming services
New or changed crontab, printer, and mail files
System log, message, and accounting files
If Solaris auditing is used, modifications to auditing files copied from the global zone might be required. For more information, see Using Solaris Auditing in Zones.
The following features cannot be configured in a non-global zone:
Solaris Live Upgrade boot environments
Solaris Volume Manager metadevices
DHCP address assignment in a shared-IP zone
SSL proxy server
The resources specified in the configuration file are added when the zone transitions from installed to ready. A unique zone ID is assigned by the system. File systems are mounted, network interfaces are set up, and devices are configured. Transitioning into the ready state prepares the virtual platform to begin running user processes. In the ready state, the zsched and zoneadmd processes are started to manage the virtual platform.
zsched, a system scheduling process similar to sched, is used to track kernel resources associated with the zone.
zoneadmd is the zones administration daemon.
A zone in the ready state does not have any user processes executing in it. The primary difference between a ready zone and a running zone is that at least one process is executing in a running zone. See the init(1M) man page for more information.
The zones administration daemon, zoneadmd, is the primary process for managing the zone's virtual platform. The daemon is also responsible for managing zone booting and shutting down. There is one zoneadmd process running for each active (ready, running, or shutting down) zone on the system.
The zoneadmd daemon sets up the zone as specified in the zone configuration. This process includes the following actions:
Allocating the zone ID and starting the zsched system process.
Setting zone-wide resource controls.
Preparing the zone's devices as specified in the zone configuration. For more information, see the devfsadmd(1M) man page.
Setting up virtual network interfaces.
Mounting loopback and conventional file systems.
Instantiating and initializing the zone console device.
Unless the zoneadmd daemon is already running, it is automatically started by zoneadm. Thus, if the daemon is not running for any reason, any invocation of zoneadm to administer the zone will restart zoneadmd.
The man page for the zoneadmd daemon is zoneadmd(1M).
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.
The zoneadm command is used to create the zone application environment.
Before 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. The application environment is established by responding to a series of prompts that appear on the zone console, as explained in Internal Zone Configuration. Note that the default locale and time zone for a zone can be configured independently of the global settings.
This section provides an overview of the procedures for halting, rebooting, and uninstalling zones. Troubleshooting tips for zones that fail to halt when requested are also provided.
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.
The following definitions apply:
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).
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:
Prints standard per-service output and all svc.startd messages to log.
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:
Prints standard per-service output and error messages requiring administrative intervention
Prints standard per-service output and messages providing more information.
Boots only to milestone svc:/milestone/single-user:default. This milestone is equivalent to init level s.
For information on the Solaris service management facility (SMF) and init , see Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration, svc.startd(1M) and init(1M).
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 the zones to autoboot, the zones service svc:/system/zones:default must also be enabled.
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.
Cloning allows you to copy an existing configured and installed zone on your system to rapidly provision a new zone on the same system. Note that at a minimum, you must reset properties and resources for the components that cannot be identical for different zones. Thus, the zonepath must always be changed. In addition, for a shared-IP zone, the IP addresses in any net resources must be different. For an exclusive-IP zone, the physical property of any net resources must be different.
Cloning a zone is a faster way to install a zone.
The new zone will include any changes that have been made to customize the source zone, such as added packages or file modifications.
Solaris 10 5/09: 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 Oracle 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 Solaris 10 5/09: How to Clone a Zone from an Existing Snapshot.
Because the contents of a snapshot 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.
You can specify that a ZFS zonepath be copied instead of ZFS cloned, even though the source could be cloned in this way.
See Solaris 10 11/06: Cloning a Non-Global Zone on the Same System for more information.