Print-friendly Version

Using Solaris Containers to Host Solaris 8 and 9 Environments on the Solaris 10 OS

Penny Cotten, May 2008

This article discusses using Solaris Containers technology to upgrade your system to the Solaris 10 release from an earlier Solaris release.

How Containers Aid in Updating to the Solaris 10 Release

A Solaris Container, also known as a zone, is a virtualized operating system environment created within a single instance of the Solaris 10 Operating System. This partitioning technology is used to virtualize operating system services and provide an isolated and secure environment for running applications. When you create a container, 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 container from monitoring or affecting processes that are running in other containers.

Containers can enable you to update to the Solaris 10 release from the Solaris 8 and 9 releases even if you are running applications that cannot be ported to the Solaris 10 platform. The software allows you to run most Solaris 8 and Solaris 9 applications, unchanged, on the latest SPARC systems and Solaris 10.

An existing Solaris 8 system can be directly migrated into a Solaris 8 container. An existing Solaris 9 system can be directly migrated into a Solaris 9 container. The original host is not modified during the migration process.

The hardware platform of the target Solaris 10 host does not need to be supported by the Solaris 8 or Solaris 9 host being migrated. Starting with the Solaris 10 8/07 release, any SPARC hardware platform can host these containers, including sun4v Logical Domains.

Factors That Determine Whether a Host Can Be Migrated

These factors determine if the Solaris 8 or Solaris 9 host is able to be migrated:

• The particular Solaris services, features, and applications that are enabled on the host.

• The Solaris 10 privileges required by the services, features, and applications.

These factors generally do not affect migration capability:

• The original Solaris 8 or Solaris 9 host hardware.

• The version or patch level of Solaris 8 or Solaris 9 that the host is running. The latest patch level is always recommended, however.

  An existing Solaris 8 system would preferably be running the Solaris 8 2/04 release.

If required by a feature, you can configure a zone that has a dedicated network adapter. You can also retain the host ID of the original host system by using a configuration attribute if required by an application.

Applications that attempt to directly access the kernel or devices will typically not function inside a container, although it is possible to make a device available within a specific container if security considerations permit.

To find out more, see Related Information. Your service provider can offer specific information on services and application types which can and cannot be migrated into a container.

About the Technology

Solaris 8 and Solaris 9 Operating System application environments are moved to new systems running the Solaris 10 release by transferring the environments to the destination system and placing them in a Solaris 8 or Solaris 9 container. The container utilizes the branded zone, or BrandZ, framework. The containers created are solaris8 and solaris9 branded zones.

The container provides a virtual mapping from the application to the platform resources. Zones allow application components to be isolated from one another even though the zones share a single instance of the Solaris 10 Operating System. Resource management features permit you to allocate the quantity of resources that a workload receives. The container establishes boundaries for resource consumption, such as CPU utilization. These boundaries can be expanded to adapt to changing processing requirements of the application running in the container.

For more information on Solaris Zones and branded zones technology, see the documents in Related Information.

Archive Creation, Configuration, and Installation

Standard archiving tools are used to create an image of an installed Solaris 8 or Solaris 9 system that can be migrated into a zone. The image can be fully configured with all of the software that will be run in the zone. This image is used when the zone is installed.

The zone installation makes the configured Solaris 8 or Solaris 9 container with the data copied from the source system ready to run on the new system. The installation adds any required patches to the Solaris 8 or 9 image to make it work correctly on the new system. The installation does not install a new version of Solaris 8 or Solaris 9.

For specific procedures, see the Solaris Container guides in Related Information.

Solaris 10 Features That Can Be Used With Solaris 8 and Solaris 9 Containers

Many Solaris 10 features can be used in combination with Solaris 8 and Solaris 9 Containers.

• ZFS

  • A Solaris Container can reside on a ZFS file system. ZFS operations such as snapshot and clone are available.

  • ZFS zvols can be exported to Solaris Containers as devices. ZFS datasets cannot be exported to Solaris 8 and Solaris 9 Containers because Solaris 8 and Solaris 9 releases have no utilities to manipulate them.

• Solaris Container Features

  • Solaris 8 and Solaris 9 Containers can be cloned and migrated between Solaris 10 hosts.

  • Zones features such as the following can be used:

    • Stack instances

    • Adding file systems

    • Adding disk, block. and character devices

• Solaris Least Privileges

  Solaris 8 and Solaris 9 Containers can be given more or fewer privileges, just like a native zone. This can enable the zone to run utilities such as ntp or snoop.

• Resource Management Features

  All resource management features available through the zonecfg utility, such as CPU assignment, memory controls, resource controls, and resource pools, can be used.

• DTrace

  The dtrace program can be run from the global zone to examine processes in solaris8 and solaris9 branded zones.

• FMA

  An uncorrectable hardware fault detected inside an application running within the container kills the application, and reboots the zone. The fault will be isolated so that other zones on the same system will not be affected.

Related Information

For more information about Solaris Containers, see:

• Solaris Containers

• System Administration Guide: Solaris 8 Containers

• System Administration Guide: Solaris 9 Containers

• System Administration Guide: Solaris Containers-Resource Management and Solaris Zones

• OpenSolaris Zones Community

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.