Sun Certified System Administrator for Solaris 10 Study Guide Exams 310-XXX & 310-XXX

Certification Objective 15.05—Managing Solaris Zones

In the good old days of computing, there was one operating system such as DOS (disk operating system) running on a machine and managing resources for one application and one user at a time. However, UNIX has been a multiuser and multi-process operating system from the very beginning. This means one operating system running on one machine and managing resources for multiple applications running concurrently and multiple users logged into the system at the same time.

The main, advantages of running multiple applications on the same machine under one operating system are wise use of resources and ease of administration (it's easier to administer one machine as opposed to ten machines, for example). The main advantages of applications running on different machines under different copies (instances) of the same operating system such as Solaris are that the applications can communicate with each other only through network APIs. Hence, they are secured from each other, and a heavy use of resources by one application does not affect the performance of the other application on another machine.

Now that computer systems are increasingly becoming more powerful in resources such as disk space, memory, and CPU power, it makes sense to consolidate applications running on different systems to one system. The problem is that if you do that, the applications, though they may currently have no resource shortage, will lose the other benefits of running in an isolated environment. So the question is: how can I run multiple applications on the same machine and still provide each application (or a group of applications) the isolated environment as if it were running on a machine of its own? That means having more than one operating system environment on one machine. So the computing model we are talking about now is: multiple instances of an operating system running on the same machine, each instance providing an isolated environment to the processes running under it as if they were running on a machine of their own. These isolated environments are provided by Solaris 10 and are called zones.

Understanding Zones

Exam Objective 6.1: Explain consolidation issues, 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.

A Solaris zone is a virtual operating system environment created by one instance of the Solaris operating system. There may be more than one zone on the same machine, and processes running in one zone cannot monitor or affect the processes running in other zones. Processes running in different zones can interact with each other only through network APIs. In other words, the processes running in a zone are isolated from processes in other zones, as though each zone were a machine (box) on its own. Actually, zone technology provides an abstract layer that separates applications from the physical attributes of the machine, such as physical device paths, on which they are deployed.

Before diving into the details of zone technology, you should understand the basic concepts described here:

• Zone types. When we refer to zones, we mean the non-global zones unless specified otherwise. Each Solaris system has a default zone called the global zone that exists even before you create additional zones (i.e., non-global zones). Even after you create zones, the global zone continues to exist and can be used for systemwide administration. Table 15-3 compares the characteristics of a global zone with those of the non-global zones.

• Networking. The processes running in one zone can interact with processes running in other zones only through network APIs. Yes, each zone that needs network connectivity has one or more dedicated IP addresses. In other words, each zone (that provides network connectivity) has at least one logical network interface, and the application running in one zone cannot view (or monitor) the network traffic for another zone. So, you can run network services confined to a zone. You can use the ifconfig command from the global zone to add or remove logical network interfaces in a running zone.

• Daemons. Because the zones can communicate with each other only over the network, they can all run their own server daemons. A specific server daemon, for example, ftpd, can run on the same port, say TCP port 21, in each zone without creating any conflict.

• Command scope. When you issue a command in a zone, you need to be aware of the command scope, which can be global (i.e., at zone level), or resource specific (i.e., specific to a resource). For example, if you are adding a resource type to a zone, the command scope is global; if you are adding a property to a specific resource, the command scope is resource specific.

A natural question to ask at this point is: how are the zones created and managed? The administrator for the global zone, referred to as the global administrator, has superuser privileges for the whole system. The global administrator, who has the primary administrator role, uses the zonecfg command to configure the zone and the zoneadm command to install software in the zone and to boot the zone. The global administrator can also assign a zone-management profile to a zone administrator whose privileges would be confined to that specific zone.

You can create a zone and delete a zone. At a given moment in its life cycle, a non-global zone can be in one of the following six states:

• Configured. The zone in this state has already been configured and the configuration parameters have been committed to permanent storage. The parameters of the zone's application environment that will be specified after the initial boot are not yet present.

• Incomplete. The zone is in the middle of state transition by an operation such as install or uninstall.

• Installed. The zone's configuration has been instantiated, but the zone's virtual platform is not yet associated with it. Software packages are installed under the root path for the zone. Before installing, you can use the zoneadm command to verify that the current configuration can be successfully used on this Solaris system.

• Ready. A virtual platform has been associated with the installed zone, and a unique zone ID has been assigned, file systems have been mounted, and devices have been configured. The kernel creates the zsched process, but no processes associated with this zone have yet been started.

• Running. One or more user processes associated with the zone's application environment are running. When the first user process associated with the zone's application environment (init) is created, the zone enters the running state.

• Shutting down, and down. Like the incomplete state, shutting down and down are the transitional states that indicate that the zone is being halted. However, the zone can get stuck in one of these states if it is unable to halt for whatever reason.

The benefits provided by the non-global zones are discussed here in terms of features:

• Security. The isolated environments created by the zones provide process security and network security. Once a process has been created in a zone, neither the process nor any of its child processes can change zones. The processes running in one zone are isolated and hence secure from processes running in other zones. By running network services in a zone, you limit the damage that can be caused in the event of a security violation. For example, the actions of an intruder who successfully breaks into the zone by exploiting a security flaw in software running in the zone are confined to that zone. The applications running in different zones on the same system are unable to monitor or intercept each other's network traffic, file system data, or process activity.

• Virtualization. In a non-zone world, multiple insolated application environments (including physical devices, IP address, and host name) can be established on different machines, one environment per machine. The zones allow you to create these isolated environments on one machine, one environment per zone. In other words, you virtualize multiple environments on the same machine. You can also split the administrator responsibilities of zones among different zone administrators.

• Granularity. You have the flexibility to choose the level of granularity in isolation provided by the zones.

• Environment. Think of a zone as a virtual machine that offers the isolated application, environment that a computer machine would offer, only with a number of isolated virtual environments on one real machine. Other than that, the zones do not change the environment in which applications execute—for example, they do not introduce a new API to which applications have to be ported. They just provide standard Solaris environments separated from each other on a single system.

Before you can install a zone and use it, it must be configured,

Configuring a Zone

Exam Objective 6.2: 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.

You can use the zonecfg utility to set up the zone configuration, which includes creating and modifying the zone configuration. Configuring a zone includes configuring zone components—its resources and properties. A property may belong to the zone (a global property) or to a particular resource. The zone configuration consists of resources described here:

• The file system (fs). Each zone can have a number of file systems, which are mounted when the zone transitions from the installed state to the ready state. The file systems mounted in a zone can include the following:

  • File systems specified in the zone's /etc/vfstab file

  • AutoFS and file systems whose mounts are triggered by AutoFS

  • Other file systems mounted by the zone administrator

• Net. The virtual interface name (logical interface). The network interface is plumbed when the zone transitions from the installed state to the ready state.

• Device, The zonecfg command uses a rule-matching system to determine the devices that should be included in a specific zone; any device that matches one of the rules is included in the zone's /dev file system.

• Resource control (rctl). The global administrator can set the zone-wide resource controls, which limit the total resource usage of all process entities within the zone.

• Attribute (attr). General attributes (defined with name-value pairs) that can be used for user comments, for example.

Once you include a resource in a zone, you also need to assign appropriate properties to the resource. You can also assign properties to the zone, called global properties. The zone configuration contains the following properties:

• Zone name. Identifies the zone to the configuration and admin utilities. In naming a zone, obey the following rules:

  • Each zone must have a unique name.

  • A zone name is case sensitive.

  • A zone name must begin with an alphanumeric character.

• Zone path. Specifies path to the zone's file system. You must choose a name and path for your zone.

• Autoboot. A Boolean whose value indicates whether the zone is booted automatically when the system boots. The default value for this property is false.

• Pool. Specifies the name of the resource pool to which this zone must be bound when booted. Multiple zones can share the resources of one pool.

• Net. The IP address and the name of the physical network interface. Each zone that needs network connectivity must have one or more IP addresses associated with the logical network interfaces.

The zonecfg command can be used in any of the three available modes: interactive mode, command-line mode, or command-file mode.

You can use the zonecfg command to get through the following three stages of configurations:

• Creating the zone configuration

• Verifying that all the required information exists

• Committing the zone configuration—that is, saving the configuration parameters to the permanent storage.

You can start the interactive session with the zonecfg utility by issuing the following command from the global zone:

zonecfg -z <zoneName>

The <zoneName> argument specifies the name of the zone to be created. Then, on the zonecfg command prompt you can issue appropriate subcommands to perform various configuration tasks, as shown in Table 15-4.

Note the difference between the remove and delete subcommands; The remove command removes a resource type or properties of a resource type, whereas delete destroys the entire zone configuration.

Note the following important points related to the zone configuration:

• A zone name must begin with an alphanumeric character followed by characters that may include alphanumeric characters, an underscore (_), or a hyphen. (-). The name global and any name beginning with a prefix SUNW are reserved and therefore are not allowed.

• When you change the parameters of a running zone by using the zonecfg command, it does not affect the zone immediately. You must reboot the zone for the changes to take effect.

• The effect of the delete subcommand is instantaneous, no commit is required in this case, and the deleted zone cannot be reverted.

• Once you use the exit subcommand to exit the zonecfg utility, the configuration will be automatically committed even if you did not use the commit command.

The following exercise demonstrates how to use the zonecfg command in its interactive mode.

Exercise 15-1: Configuring a Zone

This exercise demonstrates how to use the zoncefg command and some of its subcommands to configure a zone.

1. Become superuser in the global zone. If you have not created any zone yet, you are in the global zone.

2. Create a zone named senate-zone (as an example) by issuing the following command:

   # zonecfg -z senate-zone

   If you are configuring this zone for the first time, the following system message will appear:

   senate-zone: No such zone configured Use 'create' to begin configuring a new zone.

3. Create the configuration for the senate-zone by issuing the create command at the zone prompt:

   zonecfg:senate-zone> create

4. Set the zone path to, for example, /export/home/senate-zone:

   zonecfg:senate-zone> set zonepath=/export/home/senate-zone

5. Set the value of the autoboot property so that the zone is automatically booted when the global zone is booted.

   zonecfg:senate-zone> set autoboot=true

6. Add the virtual network interface to the zone senate-zone.

   1. Start setting up the interface with the following command:

      zonecfg:senate-zone> add net

   2. Assign the IP address 192.168.1.1 to the network interface.

      zonecfg:senate-zone:net> set address=192.168.1.1

   3. Set the physical device type for the network interface, such as hme0.

      zonecfg:senate-zone:net> set physical=hme0

7. End this specification for the resource net:

   zonecfg:senate-zone:net> end

   The prompt returns back to the zone level:

   zonecfg:senate-zone>

8. Exit the zonecfg command:

   zonecfg:senate-zone> exit

Note that once you exit the zonecfg command, the configuration will be automatically committed even if you did not use the commit command.

After you have configured a non-global zone, you can install it after verifying that the zone can be installed safely on your system's configuration. After that, you can perform other administration tasks on the zone.

Administering a Zone

Exam Objective 6.3: Given a scenario, use the zoneadm command to view, install, boot, halt, reboot, and delete a zone.

For each zone that is in the ready, running, or shutting-down state, there is one zone administration daemon, zoneadmd, running to manage the zone, which includes booting and shutting down in addition to other tasks. If the daemon is not running for any reason, an invocation of the zoneadm command will start it. Although the daemon does the work, you use the zoneadm command to administer the zone.

You can use the zoneadm command from the global zone to install and administer non-global zones. By using the zoneadm command, you can perform the following tasks:

• Verify a zone. It's a good idea to verify a zone's configuration before installing it. You can use the verify subcommand with the zoneadm command for this task. Remember that the verify subcommand is also available in the zonecfg utility.

• Install and uninstall a zone. The install subcommand is used to install a configured zone, and the uninstall subcommand to uninstall an installed zone. Uninstalling a zone involves uninstalling all the files under the zone's root file system. If you do not use the -F option, the command prompts you for confirmation.

• Boot or reboot a zone. The boot subcommand is used to boot a zone in installed or ready state and puts the zone into the running state, whereas the reboot command is used to boot a zone that is halted.

• Display information about zones. Display information about zones in various states by using the list subcommand.

• Halt a zone. The halt subcommand is used with the zoneadm command to halt a running zone. Halting a zone removes both the application environment and the virtual platform for the zone. Halting a zone kills all the processes in the zone, unconfigures the devices, unplumbs the network interfaces, unmounts the file systems, and destroys the kernel data structures. The zone is put back into the installed state. If a zone fails to halt, you may need to intervene and perform a few tasks manually. The most common reason for a halt failure is the inability of the system to unmount all the file systems in the zone.

The subcommands used with the zoneadm command to perform zone administration tasks are shown in Table 15-5. These subcommands have very trivial names. However, the trick here is to understand the conditions under which each of these commands can be issued. In other words, before issuing any of these subcommands you have to ask two questions:

• Which state is the zone in? You can find that out with the zoneadm list -v command.

• Does the subcommand I'm going to use apply on this state?

To understand in which zone state a specific subcommand can be applied, you need to understand the states we described previously in this section. The relationships of the states of a zone with each other defined by the transition of states by using the subcommands (with the zoneadm command) are shown in Figure 15-3, where the arrows indicate the transitions between states.

Figure 15-3: Various zone states in the life cycle of a zone (the create and delete subcommands are used with the zonecfg command, and the other subcommands shown are used with the zoneadm command)

After a zone has been installed, you can log into the zone by using the zlogin command to complete its application environment. The zlogin command can also be used to shut down the zone as shown, here:

zlogin <zoneName> shutdown

If you want to delete a zone, it must be put back into the configured state—that is, if it is running, it must be shut down either by using the halt command or by using the shutdown command, and then it must be uninstalled. Exercise 15-2 demonstrates how to delete a non-global zone.

Exercise 15.2: Deleting a Non-Global Zone

This exercise shows you how to delete a running zone named senate-zone, as an example. All the commands in this exercise are issued from the global zone.

1. Shut down the zone senate-zone by issuing the following command from the global zone:

   zlogin senate-zone shutdown

2. Uninstall the root file system for senate-zone by issuing the following command:

   zoneadm -z senate-zone uninstall -F

3. Delete the configuration for senate-zone by issuing the following command:

   zonecfg -z senate-zone delete -F

4. Verify the zone deletion. To verify that senate-zone is not listed, issue the following command:

   zoneadm list -iv

   The output of this command will be like the following:

   ID NAME STATE PATH 0 global running /

The three most important takeaways from this chapter are:

• The JumpStart method is used to automate the Solaris installation on a group of machines with identical configuration and software requirements. The automation is achieved by storing the information required for installation in a number of files such as sysidcfg, rules, and profile files. The flash archive method is used to install the image of an already installed Solaris environment.

• An x86 machine that supports PXE boot can be booted over a network.

• Solaris zones technology allows you to install multiple separated Solaris environments on the same machine instead of on separate machines.