Solaris Zones

Objectives:

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.

Zone States

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

State	Description
Configured	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.
Incomplete	A zone is set to this state during an install or uninstall operation. Upon completion of the operation, it changes to the correct state.
Installed	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.
Ready	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.
Running	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.

Zone Features

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.

Zone Daemons

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

Subcommand	Description
help	Print general help, or help about a specific resource.
create	Begin configuring a zone. This starts a configuration in memory for a new zone.
export	Print the configuration to stdout, or to a specified file name, which can be used as a command file.
add	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	Set a specified property name to a specified property value.
select	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.
remove	In the global scope, remove the specified resource type. You have to enter sufficient property name-value pairs to uniquely identify the required resource.
end	This is only available in the resource scope and ends the current resource specification.
cancel	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.
delete	Destroy the specified configuration. You need to use the -F option to force deletion with this option.
info	Display information about the current configuration. If a resource type is specified, then display information about the resource type.
verify	Verify the current configuration to ensure all resources have the required properties specified.
commit	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	Revert the configuration to the last committed state.
exit -F	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

Resource Type	Description
zonename	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.
zonepath	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.
fs	Each zone can mount file systems. This resource specifies the path to the file system mount point.
inherit-pkg-dir	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.
net	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.
device	Each zone can have devices that are configured when the zone transitions from the installed state to the ready state.
rctl	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.
attr	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]
  zonecfg:apps:fs> end

  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.

• inherit-pkg-dir dir

  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
  zonecfg:apps:inherit-pkg-dir> end

• net   address, physical

  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
  zonecfg:apps:net> end

• device   match

  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
  zonecfg:apps:device> end

• rctl   name, value

  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)
  zonecfg:apps:rctl> end

• attr   name, type, value

  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"
  zonecfg:apps:attr> end

Viewing the Zone Configuration

The zone configuration data can be viewed in two ways:

• Viewing a file

• Using the export option of zonecfg

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:

zoneadm -z testzone boot

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.

Halting a Zone

To shut down a zone, issue the halt option of the zoneadm command as shown in the following:

zoneadm -z testzone halt

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.

Zone Login

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

Option	Description
-C	A connection is made to the zone's console device and zlogin operates in console mode.
-e c	Changes the Escape sequence to exit from the console session, the default is the tilde (~).
-E	Disables the use of extended functions and also prohibits the use of the Escape sequence to disconnect from the session.
-l username	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.
-S	"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.
zonename	Specifies the zone to connect to.
utility	Specifies the utility, or command, to run in the zone.
argument	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:

• Language

• Terminal Type

• Host name

• Security Policy

• Name Service

• Time Zone

• Root Password

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.

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:

lang=C
system_locale=en_GB
terminal=vt100
network_interface=primary {
     hostname=testzone
}
security_policy=NONE
name_service=NONE
timezone=GB
root_password=dKsw26jNk2CCE

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.

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.
Hostname: testzone
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.
Hostname: testzone

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
# zonename
testzone
# exit

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

# hostname
global
# zlogin testzone zonename
testzone
# hostname
global

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.

Step By Step 13.1: Creating a zone 1. 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 2. Enter the zonecfg command to configure the new zone. [View full width] # zonecfg -z testzone testzone: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:testzone>create zonecfg:testzone>set zonepath=/export/zones/testzone zonecfg:testzone>set autoboot=true zonecfg:testzone>add net zonecfg:testzone:net>set physical=hme0 zonecfg:testzone:net> zonecfg:testzone:net>set address=192.168.0.43 zonecfg:testzone:net>end zonecfg:testzone> add rctl zonecfg:testzone:rctl> set name=zone.cpu-shares zonecfg:testzone:rctl> add value (priv=privileged,limit=20 ,action=none) zonecfg:testzone:rctl> end zonecfg:testzone> add attr zonecfg:testzone:attr> set name=comment zonecfg:testzone:attr> set type=string zonecfg:testzone:attr> set value="First zone - Testzone" zonecfg:testzone:attr> end 3. 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. 4. Verify and save the zone configuration. Exit zonecfg and then check to see if the zone exists using the zoneadm command. zonecfg:testzone> verify zonecfg:testzone> commit zonecfg:testzone> exit # 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 state. 5. Use the zoneadm command to verify that the zone is correctly configured and ready to be installed: # zoneadm -z testzone verify 6. Install the zone: [View full width] # 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 /install_log> contains\ a log of the zone installation. 7. 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 8. View the configuration data by exporting the configuration to stdout. # zonecfg -z testzone export create -b set zonepath=/export/zones/testzone set autoboot=true add inherit-pkg-dir set dir=/lib end add inherit-pkg-dir set dir=/platform end add inherit-pkg-dir set dir=/sbin end add inherit-pkg-dir set dir=/usr end add net set address=192.168.0.43 set physical=hme0 end add rctl set name=zone.cpu-shares add value (priv=privileged, limit=20, action=none) end add attr set name=comment set type=string set value="First zone - Testzone" end Notice the four default inherit-pkg-dir enTRies showing that this is a sparse root zone.