Solaris 10 5/09 Installation Guide: Planning for Installation and Upgrade

Chapter 8 Upgrading When Solaris Zones Are Installed on a System (Planning)

This chapter provides an overview of how Solaris Zones partitioning technology relates to upgrading the Solaris OS when non-global zones are configured.

This chapter contains the following sections:

Solaris Zones (Overview)

The Solaris Zones partitioning technology is used to virtualize operating system services and provide an isolated and secure environment for running applications. A non-global zone is a virtualized operating system environment created within a single instance of the Solaris OS. When you create a non-global zone, you produce an application execution environment in which processes are isolated from the rest of the system. This isolation prevents processes that are running in one non-global zone from monitoring or affecting processes that are running in other non-global zones. Even a process running with superuser credentials cannot view or affect activity in other zones. A non-global zone also provides an abstract layer that separates applications from the physical attributes of the machine on which they are deployed. Examples of these attributes include physical device paths.

Every Solaris system contains a global zone. The global zone has a dual function. The global zone is both the default zone for the system and the zone used for system-wide administrative control. All processes run in the global zone if no non-global zones are created by the global administrator. The global zone is the only zone from which a non-global zone can be configured, installed, managed, or uninstalled. Only the global zone is bootable from the system hardware. Administration of the system infrastructure, such as physical devices, routing, or dynamic reconfiguration (DR), is only possible in the global zone. Appropriately privileged processes running in the global zone can access objects associated with the non-global zones.

Description	For More Information
The following sections describe how you can upgrade a system that contains non-global zones.	Upgrading With Non-Global Zones
For complete information on creating and configuring non-global zones	Chapter 16, Introduction to Solaris Zones, in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones

Upgrading With Non-Global Zones

After the Solaris OS is installed, you can install and configure non-global zones. You can upgrade the Solaris OS when non-global zones are installed. If you have branded non-global zones installed, they are ignored during the upgrade process. Installation programs that can accommodate systems that have non-global zones installed are summarized below.

Table 8–1 Choosing an Installation Program to Upgrade With Non-Global Zones


Upgrade Program	Description	For More Information
Solaris Live Upgrade	You can upgrade or patch a system that contains non-global zones. If you have a system that contains non-global zones, Solaris Live Upgrade is the recommended upgrade program or program to add patches. Other upgrade programs might require extensive upgrade time, because the time required to complete the upgrade increases linearly with the number of installed non-global zones. If you are patching a system with Solaris Live Upgrade, you do not have to take the system to single-user mode and you can maximize your system's uptime. Starting with the Solaris 10 8/07 release, changes to accommodate systems that have non-global zones installed are the following: A new package, `SUNWlucfg`, is required to be installed with the other Solaris Live Upgrade packages, `SUNWlur` and `SUNWluu`. Creating a new boot environment from the currently running boot environment remains the same with one exception. You can specify a destination slice for a shared file system within a non-global zone. This exception occurs under the following circumstances: If on the current boot environment the `zonecfg add fs` command was used that created a separate file system for a non-global zone If this separate file system resides on a shared file system, such as `/zone/root/export` To prevent this separate file system from being shared in the new boot environment, the `lucreate` command has changed to enable specifying a destination slice for a separate file system for a non-global zone. The argument to the `-m` option has a new optional field, `zonename`. This new field places the non-global zone's separate file system on a separate slice in the new boot environment. For more information on setting up a non-global zone with a separate file system, see zonecfg(1M).	For UFS file systems, for step-by-step instructions on using Solaris Live Upgrade when non-global zones are installed, see Chapter 8, Upgrading the Solaris OS on a System With Non-Global Zones Installed, in Solaris 10 5/09 Installation Guide: Solaris Live Upgrade and Upgrade Planning. For ZFS root pools, for an overview and step-by-step instructions, see Chapter 14, Solaris Live Upgrade For ZFS With Non-Global Zones Installed, in Solaris 10 5/09 Installation Guide: Solaris Live Upgrade and Upgrade Planning.
Solaris Live Upgrade continued	Note – By default, any file system other than the critical file systems (root (`/`), `/usr`, and `/opt` file systems) is shared between the current and new boot environments. Updating shared files in the active boot environment also updates data in the inactive boot environment. The `/export` file system is an example of a shared file system. If you use the `-m` option and the `zonename` option, the non-global zone's shared file system is copied to a separate slice and data is not shared. This option prevents non-global zone file systems that were created with the `zonecfg add fs` command from being shared between the boot environments. Additional changes, starting with the Solaris 10/8/07 release, that accommodate systems with non-global zones installed include the following: Comparing boot environments is enhanced. The `lucompare` command now generates a comparison of boot environments that includes the contents of any non-global zone. The `lumount` command now provides non-global zones with access to their corresponding separate file systems that exist on inactive boot environments. When the global zone administrator uses the `lumount` command to mount an inactive boot environment, the boot environment is mounted for non-global zones as well. Listing file systems with the `lufslist` command is enhanced to display a list of file systems for both the global zone and the non-global zones.
Solaris interactive installation program GUI	You can upgrade or patch a system when non-global zones are installed. The time to upgrade or patch might be extensive, depending on the number of non-global zones that are installed.	For more information about installing with this program, see Chapter 2, Installing With the Solaris Installation Program For UFS File Systems (Tasks), in Solaris 10 5/09 Installation Guide: Basic Installations.
Automated JumpStart installation	You can upgrade or patch with any keyword that applies to an upgrade or patching. The time to upgrade or patch might be extensive, depending on the number of non-global zones that are installed.	For more information about installing with this program, see Solaris 10 5/09 Installation Guide: Custom JumpStart and Advanced Installations.

Limitations when upgrading with non-global zones are listed in the following table.

Table 8–2 Limitations When Upgrading With Non-Global Zones


Program or Condition	Description	For More Information
Consider these issues when using Solaris Live Upgrade on a system with zones installed. It is critical to avoid zone state transitions during `lucreate` and `lumount` operations.	When you use the `lucreate` command to create an inactive boot environment, if a given non-global zone is not running, then the zone cannot be booted until the `lucreate` operation has completed. When you use the `lucreate` command to create an inactive boot environment if a given non-global zone is running, the zone should not be halted or rebooted until the `lucreate` operation has completed. When an inactive boot environment is mounted with the `lumount` command, you cannot boot non-global zones or reboot them, although zones that were running before the `lumount` operation can continue to run. Because a non-global zone can be controlled by a non-global zone administrator as well as by the global zone administrator, to prevent any interaction, halt all zones during `lucreate` or `lumount` operations.	For UFS file systems, for step-by-step instructions on using Solaris Live Upgrade when non-global zones are installed, see Chapter 8, Upgrading the Solaris OS on a System With Non-Global Zones Installed, in Solaris 10 5/09 Installation Guide: Solaris Live Upgrade and Upgrade Planning. For ZFS root pools, for an overview and step-by-step instructions, see Chapter 14, Solaris Live Upgrade For ZFS With Non-Global Zones Installed, in Solaris 10 5/09 Installation Guide: Solaris Live Upgrade and Upgrade Planning.
Problems can occur when the global zone administrator does not notify the non-global zone administrator of an upgrade with Solaris Live Upgrade.	When Solaris Live Upgrade operations are underway, non-global zone administrator involvement is critical. The upgrade affects the work of the administrators, who will be addressing the changes that occur as a result of the upgrade. Zone administrators should ensure that any local packages are stable throughout the sequence, handle any post-upgrade tasks such as configuration file adjustments, and generally schedule around the system outage. For example, if a non-global zone administrator adds a package while the global zone administrator is copying the file systems with the `lucreate` command, the new package is not copied with the file systems and the non-global zone administrator is unaware of the problem.
Solaris Flash archives cannot be used with non-global zones.	A Solaris Flash archive cannot be properly created when a non-global zone is installed. The Solaris Flash feature is not compatible with Solaris Zones partitioning technology. If you create a Solaris Flash archive, the resulting archive is not installed properly when the archive is deployed under these conditions: The archive is created in a non-global zone. The archive is created in a global zone that has non-global zones installed.	For more information about using Solaris Flash archives, see Solaris 10 5/09 Installation Guide: Solaris Flash Archives (Creation and Installation).
Using a command that uses the `-R` option or equivalent must not be used in some situations.	Any command that accepts an alternate root (`/`) file system by using the `-R` option or equivalent must not be used if the following are true: The command is run in the global zone. The alternative root (`/`) file system refers to any path within a non-global zone. An example is the `-R` `root_path` option to the `pkgadd` utility run from the global zone with a path to the root (`/`) file system in a non-global zone.	For a list of utilities that accept an alternate root (`/`) file system and more information about zones, see Restriction on Accessing A Non-Global Zone From the Global Zone in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.

Backing Up Your System Before Performing an Upgrade With Zones

You should back up the global and non-global zones on your Solaris system before you perform the upgrade. For information about backing up a system with zones installed, see Chapter 26, Solaris Zones Administration (Overview), in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.

Disk Space Requirements for Non-Global Zones

When installing the global zone, be sure to reserve enough disk space for all of the zones you might create. Each non-global zone might have unique disk space requirements.

No limits are placed on how much disk space can be consumed by a zone. The global zone administrator is responsible for space restriction. Even a small uniprocessor system can support a number of zones running simultaneously. The characteristics of the packages installed in the global zone affect the space requirements of the non-global zones that are created. The number of packages and space requirements are factors.

For complete planning requirements and recommendations, see Chapter 18, Planning and Configuring Non-Global Zones (Tasks), in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.