Explain consolidation issues and features of Solaris zones, and decipher between the different zone concepts including zone types, daemons, networking, command scope, and given a scenario, create a Solaris zone.
Given a zone configuration scenario, identify zone components and zonecfg resource parameters, allocate file system space, use the zonecfg command, describe the interactive configuration of a zone, and view the zone configuration file.
Given a scenario, use the zoneadm command to view, install, boot, halt, reboot, and delete a zone.
The zones technology provides virtual operating system services to allow applications to run in an isolated and secure environment. A zone is a virtual environment that is created within a single running instance of the Solaris Operating Environment. Applications running in a zone environment cannot affect applications running in a different zone, even though they exist and run on the same physical server. Even a privileged user in a zone cannot monitor or access processes running in a different zone.
Types of Zones
There are two types of zones, global and non-global. Think of a global zone as the server itself, the traditional view of a Solaris system as we all know it, where you can login as root and have full control of the entire system. The global zone is the default zone and is used for system-wide configuration and control. Every system contains a global zone and there can only be one global zone on a physical Solaris server.
A non-global zone is created from the global zone and also managed by it. You can have up to 8192 non-global zones on a single physical systemthe only real limitation is the capability of the server itself. Applications that run in a non-global zone are isolated from applications running in a separate non-global zone, allowing multiple versions of the same application to run on the same physical server.
Non-global zones are referred to simply as zones and can be in a number of states depending on the current state of configuration or readiness for operation. You should note that zone states only refer to non-global zones because the global zone is always running and represents the system itself. The only time the global zone is not running is when the server has been shut down.
Table 13.1 describes the six states that a zone can be in:
Table 13.1. Zone States
A zone is in this state when the configuration has been completed and storage has been committed. Additional configuration that must be done after the initial reboot has yet to be done.
A zone is set to this state during an install or uninstall operation. Upon completion of the operation, it changes to the correct state.
A zone in this state has a confirmed configuration. The zoneadm command is used to verify that the zone will run on the designated Solaris system. Packages have been installed under the zone's root path. Even though the zone is installed, it still has no virtual platform associated with it.
The zone's virtual platform is established. The kernel creates the zsched process, the network interfaces are plumbed and file systems are mounted. The system also assigns a zone ID at this state, but there are no processes associated with this zone.
A zone enters this state when the first user process is created. This is the normal state for an operational zone.
Shutting Down + Down
Transitional states that are only visible while a zone is in the process of being halted. If a zone cannot shut down for any reason, then it will also display this state.
Know Your Zone States There is often at least one question in the exam relating to different zone states. Pay particular attention to the differences between the configured, installed, ready, and running states. You may get a question that asks you to match the correct state to the correct description.
This section describes the features of both the global zone and non-global zones.
The global zone has the following features:
The global zone is assigned zone ID 0 by the system.
It provides the single bootable instance of the Solaris Operating Environment that runs on the system.
It contains a full installation of Solaris system packages.
It can contain additional software, packages, file, or data that was not installed through the packages mechanism.
Contains a complete product database of all installed software components.
It holds configuration information specific to the global zone, such as the global zone hostname and the file system table.
It is the only zone that is aware of all file systems and devices on the system.
It is the only zone that is aware of non-global zones and their configuration.
It is the only zone from which a non-global zone can be configured, installed, managed, and uninstalled.
Non-global zones have the following features:
The non-global zone is assigned a zone ID by the system when it is booted.
It shares the Solaris kernel that is booted from the global zone.
It contains a subset of the installed Solaris system packages.
It can contain additional software packages, shared from the global zone.
It can contain additional software packages that are not shared from the global zone.
It can contain additional software, files, or data that was not installed using the package mechanism, or shared from the global zone.
It contains a complete product database of all software components that are installed in the zone. This includes software that was installed independently of the global zone as well as software shared from the global zone.
It is not aware of the existence of other zones.
It cannot install, manage, or uninstall other zones, including itself.
It contains configuration information specific to itself, the non-global zone, such as the non-global zone hostname and file system table.
Non-Global Zone Root File System Models
A non-global zone contains its own root (/) file system. The size and contents of this file system depend on how you configure the global zone and the amount of configuration flexibility that is required.
There is no limit on how much disk space a zone can use, but the zone administrator, normally the system administrator, must ensure that sufficient local storage exists to accommodate the requirements of all non-global zones being created on the system.
The system administrator can restrict the overall size of the non-global zone file system by using any of the following:
Standard disk partitions on a disk can be used to provide a separate file system for each non-global zone
Soft partitions can be used to divide disk slices or logical volumes into a number of partitions. Soft partitions were covered in Chapter 9, "Virtual File Systems, Swap Space, and Core Dumps."
Use a lofi-mounted file system to place the zone on. For further information on the loopback device driver see the manual pages for lofi and lofiadm.
Sparse Root Zones
When you create a non-global zone, you have to decide how much of the global zone file system you want to be inherited from the global zone. A sparse root zone optimizes sharing by implementing read-only loopback file systems from the global zone and only installing a subset of the system root packages locally. The majority of the root file system is shared (inherited) from the global zone. Generally this model would require about 100 Megabytes of disk space when the global zone has all of the standard Solaris packages installed. A sparse root zone uses the inherit-pkg-dir resource, where a list of inherited directories from the global zone are specified.
Whole Root Zones
This model provides the greatest configuration flexibility because all of the required (and any other selected) Solaris packages are copied to the zone's private file system, unlike the sparse root model where loopback file systems are used. The disk space requirement for this model is considerably greater and is determined by evaluating the space used by the packages currently installed in the global zone.
Networking in a Zone Environment
On a system supporting zones the zones can communicate with each other over the network, but even though the zones reside on the same physical system, network traffic is restricted so that applications running on a specified zone cannot interfere with applications running on a different zone.
Each zone has its own set of bindings and zones can all run their own network daemons. As an example, consider three zones all providing web server facilities using the apache package. Using zones, all three zones can host websites on port 80, the default port for http TRaffic, without any interference between them. This is because the IP stack on a system supporting zones implements the separation of network traffic between zones.
The only interaction allowed is for ICMP traffic to resolve problems, so that commands such as ping can be used to check connectivity.
Of course, when a zone is running, it behaves like any other Solaris system on the network in that you can telnet or ftp to the zone as if it was any other system, assuming the zone has configured these network services for use.
When a zone is created, a dedicated IP address is configured that identifies the host associated with the zone. In reality though, the zone's IP address is configured as a logical interface on the network interface specified in the zone's configuration parameters. Only the global zone has visibility of all zones on the system and can also inspect network traffic, using for example, snoop.
The zone management service is managed through the Service Management Facility (SMF), the service identifier is called: svc:/system/zones:default
There are two daemon processes associated with zones, zoneadmd and zsched.
The zoneadmd daemon starts when a zone needs to be managed. An instance of zoneadmd will be started for each zone, so it is not uncommon to have multiple instances of this daemon running on a single server. It is started automatically by SMF and is also shut down automatically when no longer required. The zoneadmd daemon carries out the following actions:
Allocates the zone ID and starts the zsched process
Sets system-wide resource controls
Prepares the zone's devices if any are specified in the zone configuration
Plumbs the virtual network interface
Mounts any loopback or conventional file systems
The zsched process is started by zoneadmd and exists for each active zone (a zone is said to be active when in the ready, running, or shutting down state. The job of zsched is to keep track of kernel threads running within the zone. It is also known as the zone scheduler.
Configuring a Zone
Before a zone can be installed and booted it has to be created and configured. This section deals with the initial configuration of a zone and describes the zone components.
A zone is configured using the zonecfg command. The zonecfg command is also used to verify that the resources and properties that are specified during configuration are valid for use on a Solaris system. zonecfg checks that a zone path has been specified and that for each resource, all of the required properties have been specified.
The zonecfg Command
The zonecfg command is used to configure a zone. It can run interactively, on the command-line, or using a command-file. A command-file is created by using the export subcommand of zonecfg. zonecfg carries out the following operations:
Create, or delete, a zone configuration
Add, or remove, resources in a configuration
Set the properties for a resource in the configuration
Query and verify a configuration
Commit (save) a configuration
Revert to a previous configuration
Exit from a zonecfg session
When you enter zonecfg in interactive mode, the prompt changes to show that you are in a zonecfg session. If you are configuring a zone called apps, then the prompt changes as follows:
# zonecfg -z apps
This is known as the global scope of zonecfg. When you configure a specific resource, the prompt changes to include the resource being configured. The command scope also changes so that you are limited to entering commands relevant to the current scope. You have to enter an end command to return to the global scope.
Table 13.2 describes the subcommands that are available with the interactive mode of zonecfg:
Table 13.2. zonecfg Subcommands
Print general help, or help about a specific resource.
Begin configuring a zone. This starts a configuration in memory for a new zone.
Print the configuration to stdout, or to a specified file name, which can be used as a command file.
In the global scope, this command takes you to the specified resource scope. In the resource scope, it adds the specified property to the resource type.
Set a specified property name to a specified property value.
This is applicable only in the global scope and selects the resource of the specified type. The scope changes to the resource, but you have to enter sufficient property name-value pairs to uniquely identify the required resource.
In the global scope, remove the specified resource type. You have to enter sufficient property name-value pairs to uniquely identify the required resource.
This is only available in the resource scope and ends the current resource specification.
This is only available in the resource scope. It ends the resource specification and returns to the global scope. Any partially specified resources are discarded.
Destroy the specified configuration. You need to use the -F option to force deletion with this option.
Display information about the current configuration. If a resource type is specified, then display information about the resource type.
Verify the current configuration to ensure all resources have the required properties specified.
Commit the current configuration from memory to disk. A configuration must be committed before it can be used by the zoneadm command, described later in this chapter.
Revert the configuration to the last committed state.
Exit the zonecfg session. You can use the -F option with this subcommand to force the command to execute.
Table 13.3 lists the resource types that are applicable to the zonecfg command:
Table 13.3. zonecfg Resource Types
The zonename identifies the zone and must be unique. It can't be longer than 64 characters. It's case-sensitive and must begin with an alpha-numeric character. It can also contain underbars (_), hyphens (-), and periods (.). The name global and all names beginning with SUNW are reserved and not allowed.
This is the path to the zone root in relation to the global zone's root directory (/). To restrict visibility to non-privileged users in the global zone, the permissions on the zonepath directory should be set to 700.
Each zone can mount file systems. This resource specifies the path to the file system mount point.
This type specifies directories that contain software packages that are shared with the global zone, or inherited from the global zone. The non-global zone only inherits read-only access. There are four default inherit-pkg-dir resources included in the configuration, namely /lib, /sbin, /platform and /usr. The packages associated with these directories are inherited (in a read-only loopback file system mount) by the non-global zone.
Each zone can have network interfaces that are plumbed when the zone transitions from the installed state to the ready state. Network interfaces are implemented as virtual interfaces.
Each zone can have devices that are configured when the zone transitions from the installed state to the ready state.
This type is used for zone-wide resource controls. The controls are enabled when the zone transitions from the installed state to the ready state. The zone-wide resource controls implemented in Solaris 10 are zone.cpu-shares and zone.max-lwps.
This is a generic type and is most often used for comments.
Some of the resource types described in Table 13.3 also have properties that need to be configured if the resource type is to be used. The following list describes the properties and the parameters, along with examples of usage:
fs dir, special, raw, type, options
The following code gives an example of how these properties are used. The bold type indicates the keystrokes entered at the keyboard.
zonecfg:apps> add fs
zonecfg:apps:fs> set dir=/testmount
zonecfg:apps:fs> set special=/dev/dsk/c0t1d0s0
zonecfg:apps:fs> set raw=/dev/rdsk/c0t1d0s0
zonecfg:apps:fs> set type=ufs
zonecfg:apps:fs> add options [logging, nosuid]
This code example specifies that /dev/dsk/c0t1d0s0 in the global zone is to be mounted on directory /testmount in the non-global zone and the raw device /dev/rdsk/c0t1d0s0 is the device to fsck before attempting the mount. The file system is of type ufs and a couple of mount options have been added too.
This specifies the directory that is to be loopback mounted from the global zone. The following example shows that /opt/sfw is to be mounted:
zonecfg:apps> add inherit-pkg-dir
zonecfg:apps:inherit-pkg-dir> set dir=/opt/sfw
This specifies the setup of the network interface for the zone. The following code example specifies an IP address of 192.168.0.42 and that the physical interface to be used is hme0:
zonecfg:apps> add net
zonecfg:apps:net> set physical=hme0
zonecfg:apps:net> set address=192.168.0.42
This specifies a device to be included in the zone. The following code example includes a tape drive, /dev/rmt/0:
zonecfg:apps> add device
zonecfg:apps:device> set match=/dev/rmt/0
There are two zone-wide resource controls, namely zone.cpu-shares and zone.max-lwps. The zone.cpu-shares limits the zone's share of the CPU resources, and the zone.max-lwps limits the number of Lightweight Processes that the zone can run. These two controls prevent the zone from exhausting resources that could affect the performance or operation of other zones.
The following example sets the number of CPU shares to 20:
zonecfg:apps> add rctl
zonecfg:apps:rctl> set name=zone.cpu-shares
zonecfg:apps:rctl> set value=(priv=privileged,limit=20,action=none)
The attr resource type is mainly used for adding a comment to a zone. The following example adds a comment for the zone apps:
zonecfg:apps> add attr
zonecfg:apps:attr> set name=comment
zonecfg:apps:attr> set type=string
zonecfg:apps:attr> set value="The Application Zone"
Viewing the Zone Configuration
The zone configuration data can be viewed in two ways:
Both of these are described here:
The zone configuration file is held in the /etc/zones directory and is stored as an xml file. To view the configuration for a zone named testzone, you would enter:
# cat /etc/zones/testzone.xml
The alternative method of viewing the configuration is to use the zonecfg command with the export option. The following example shows how to export the configuration data for zone testzone:
# zonecfg -z testzone export
By default, the output goes to stdout, but this can be changed by entering a filename instead. If you save the configuration to a file, then it can be used at a later date, if required, as a command file input to the zonecfg command. This option is useful if you have to recreate the zone for any reason.
Installing a Zone
When a zone has been configured, the next step in its creation is to install it. This has the effect of copying the necessary files from the global zone and populating the product database for the zone. You should verify a configuration before it is installed to ensure that everything is set up correctly.
To verify the zone configuration for a zone named testzone enter the following command:
zoneadm -z testzone verify
If, for example, the zonepath does not exist, or it has not had the correct permissions set, then the verify operation will generate a suitable error message.
When the zone has been successfully verified it can be installed, as follows:
zoneadm -z testzone install
A number of status and progress messages are displayed on the screen as the files are copied and the package database is updated.
Notice that whilst the zone is installing, its state will change from configured to incomplete. The state will change to installed when the install operation has completed.
Booting a Zone
Before issuing the boot command, a zone needs to be transitioned to the ready state. This can be done using the zoneadm command as follows:
zoneadm -z testzone ready
The effect of the ready command is to establish the virtual platform, plumb the network interface and mount any file systems. At this point though, there are no processes running.
To boot the zone testzone, issue the following command:
Confirm that the zone has booted successfully by listing the zone using the zoneadm command as follows:
zoneadm -z testzone list -v
The state of the zone will have changed to running if the boot operation was successful.
No Need to Ready If you want to boot a zone, then there is no need to transition to the ready state. The boot operation does this automatically prior to booting the zone.
Halting a Zone
To shut down a zone, issue the halt option of the zoneadm command as shown in the following:
The zone state changes from running to installed when a zone is halted.
Rebooting a Zone
A zone can be rebooted at any time without affecting any other zone on the system. The reboot option of the zoneadm command is used to reboot a zone as shown here to reboot the zone testzone:
zoneadm -z testzone reboot
The state of the zone should be running when the reboot operation has completed.
Uninstalling a Zone
When a zone is no longer required, it should be uninstalled before it is deleted. In order to uninstall a zone, it must first be halted. When this has been done, issue the uninstall command as shown here to uninstall the zone testzone:
zoneadm -z testzone uninstall -F
The -F option forces the command to execute without confirmation. If you omit this option, then you will be asked to confirm that you wish to uninstall the zone.
Deleting a Zone
When a zone has been successfully uninstalled, its configuration can be deleted from the system. Enter the zonecfg command as shown here to delete the zone testzone from the system:
zonecfg -z testzone delete -F
The -F option forces the command to execute without confirmation. If you omit this option, then you will be asked to confirm that you wish to delete the zone configuration.
Remember the Force Unlike most other Unix commands, zoneadm and zonecfg use an uppercase letter F to force the command to be executed without prompting you for confirmation. All other commands, such as mv, rm, and umount, for example, always use a lowercase letter f. Make sure you are aware of this anomaly when you sit for the exam.
When a zone is operational and running, the normal network access commands can be used to access a zone, such as telnet, rlogin, and ssh, but a non-global zone can also be accessed from the global zone using zlogin command. This is necessary for administration purposes and to be able to access the console session for a zone. Only the Superuser (root), or a role with the RBAC profile "Zone Management" can use the zlogin command from the global zone.
The syntax for the zlogin command is as follows:
zlogin [-CE] [-e c] [-l username] zonename
zlogin [-ES] [-e c] [-l username] zonename utility [argument...]
zlogin works in three modes:
Interactivewhere a login session is established from the global zone.
Non-interactivewhere a single command or utility can be executed. Upon completion of the command (or utility), the session is automatically closed.
Consolewhere a console session is established for administration purposes.
Table 13.4 describes the various options for zlogin:
Table 13.4. zlogin Options
A connection is made to the zone's console device and zlogin operates in console mode.
Changes the Escape sequence to exit from the console session, the default is the tilde (~).
Disables the use of extended functions and also prohibits the use of the Escape sequence to disconnect from the session.
Specifies a different user for the zone login. User root is used when this option is omitted. This option cannot be used when using zlogin in console mode.
"Safe" login mode. This option is used to recover a damaged zone when other login forms do not work. This option cannot be used in console mode.
Specifies the zone to connect to.
Specifies the utility, or command, to run in the zone.
This option allows arguments to be specified and passed to the utility or command being executed.
Initial Zone Login
When a zone has been installed and is booted for the first time, it is still not fully operational because the internal zone configuration needs to be completed. This includes setting the following:
These settings are configured interactively the first time you use zlogin to connect to the zone console, similar to when you first install the Solaris 10 Operating Environment. The zone then reboots to implement the changes. When this reboot completes, the zone is fully operational.
Initial Console Login You must complete the configuration by establishing a console connection. If this is not completed, the zone will not be operational and users will be unable to connect to the zone across the network.
Using a sysidcfg File
Instead of completing the zone configuration interactively, you can pre-configure the required options in a sysidcfg file. This enables the zone configuration to be completed without intervention. The sysidcfg file needs to be placed in the /etc directory of the zone's root. For a zone named testzone with a zonepath of /export/zones/testzone, the sysidcfg file would be placed in /export/zones/testzone/root/etc.
The following example of a sysidcfg file sets the required parameters, but doesn't use a naming service, or a security policy. Note that the root password entry needs to include the encrypted password:
There is one other question that is asked by the zone configuration utility, relating to NFS version 4 domain parameter. To complete a hands-off configuration, create the following file in the zone's root/etc directory:
# touch /export/zones/testzone/root/etc/.NFS4inst_state.domain
This file indicates that the NFSv4 domain has been set, so you don't get asked to confirm it.
Install sysidcfg Before Boot You need to install the sysidcfg file and create the .NFS4inst_state.domain file before the initial boot of the zone, otherwise the files will be ignored and you will have to complete the zone setup interactively.
Logging in to the Zone Console
You can access the console of a zone by using the zlogin -C <zonename> command. If you are completing a hands-off configuration, connect to the console before the initial boot and you will see the boot messages appear in the console as well as the reboot after the sysidcfg file has been referenced.
The following session shows what happens when the zone testzone is booted for the first time, using a sysidcfg file:
# zlogin -C testzone
[NOTICE: Zone readied]
[NOTICE: Zone booting up]
SunOS Release 5.10 Version Generic 64-bit
Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Loading smf(5) service descriptions: 100/100
Creating new rsa public/private host key pair
Creating new dsa public/private host key pair
rebooting system due to change(s) in /etc/default/init
[NOTICE: Zone rebooting]
SunOS Release 5.10 Version Generic 64-bit
Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
testzone console login:
Logging in to a Zone
The Superuser (root), or a role with the RBAC profile "Zone Management", can log directly into a zone from the global zone, without having to supply a password. The system administrator uses the zlogin command; the following example shows a zone login to the testzone zone, the command zonename is run and then the connection is closed:
# zlogin testzone
[Connected to zone 'testzone' pts/6]
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
[Connection to zone 'testzone' pts/6 closed]
Running a Command in a Zone
In the previous section an interactive login to a zone was achieved. Here, a non-interactive login is actioned and a single command is executed. The connection is automatically disconnected as soon as the command has completed. The following example shows how this works. First, the hostname command is run, demonstrating that we are on the host called global, then a non-interactive login to the testzone zone runs, which runs the zonename command and then exits automatically. Finally, the same hostname command is run, which shows we are back on the host called global:
# zlogin testzone zonename
No -z in zlogin Be careful not to include the -z option when answering questions on zlogin in the exam. It's easy to get confused with the zoneadm command, where the -z option IS used.
Creating a Zone
Now that we have seen the technicalities of configuring a zone, let's put it all together and create a zone. Step by Step 13.1 configures the zone named testzone, installs it and boots it. Finally, we will list the zone configuration data.
Perform the initial configuration on a zone named testzone
. The zonepath will be /export/zones/testzone
and the IP address will be 192.168.0.43
. This zone will be a sparse root
zone with no additional file systems being mounted from the global zone. Create the zonepath and assign the correct permission (700
) to the directory. The bold
text identifies the keystrokes to be entered at the keyboard:
# mkdir -p /export/zones/testzone
# chmod 700 /export/zones/testzone
Enter the zonecfg
command to configure the new zone.
# zonecfg -z testzone
testzone: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:testzone:net> zonecfg:testzone:net>set address=192.168.0.43
zonecfg:testzone> add rctl
zonecfg:testzone:rctl> set name=zone.cpu-shares
zonecfg:testzone:rctl> add value (priv=privileged,limit=20
zonecfg:testzone> add attr
zonecfg:testzone:attr> set name=comment
zonecfg:testzone:attr> set type=string
zonecfg:testzone:attr> set value="First zone - Testzone"
Having entered the initial configuration information, use a separate login session to check to see if the zone exists using the zoneadm command
# zoneadm -z testzone list -v
zoneadm: testzone: No such zone configured
At this point the zone configuration has not been committed and saved to disk, so it only exists in memory.
Verify and save the zone configuration. Exit zonecfg
and then check to see if the zone exists using the zoneadm
# zoneadm -z testzone list -v
ID NAME STATUS PATH
- testzone configured /export/zones/testzone
Notice that the zone now exists and that it has been placed in the configured
Use the zoneadm
command to verify that the zone is correctly configured and ready to be installed:
# zoneadm -z testzone verify
Install the zone:
# zoneadm -z testzone install
Preparing to install zone <testzone>.
Creating list of files to copy from the global zone.
Copying <77108> files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize <1141> packages on the zone.
Initialized <1141> packages on zone.
Zone <testzone> is initialized.
The file </export/zones/testzone/root/var/sadm/system/logs
a log of the zone installation.
The zone is now ready to be used operationally. Change the state to ready
and verify that it has changed, then boot the zone and check that the state has changed to running
# zoneadm -z testzone ready
# zoneadm -z testzone list -v
ID NAME STATUS PATH
7 testzone ready /export/zones/testzone
# zoneadm -z testzone boot
# zoneadm -z testzone list -v
ID NAME STATUS PATH
7 testzone running /export/zones/testzone
View the configuration data by exporting the configuration to stdout
# zonecfg -z testzone export
add value (priv=privileged, limit=20, action=none)
set value="First zone - Testzone"
Notice the four default inherit-pkg-dir
enTRies showing that this is a sparse root zone
Zone Configuration File You can also view the configuration file directly by viewing /etc/zones/<zonename>.xml. This file is created when you save the configuration using zonecfg. You might be asked this location in the exam.