Solaris 10 Zones Examples

This section contains a brief description of Solaris 10 zones support
for the current release of Java ES. Installation sequence examples are included.
The following topics are addressed in this section:

Overview of Solaris Zones

The Solaris 10 zones feature (also known as Solaris containers) provides
a means of creating virtualized operating system environments within an instance
of Solaris OS. This allows one or more processes to run in isolation from
other activities on the host. For example, a process running in a zone will
only be able to send signals to other processes in the same zone, regardless
of user ID and other credential information.

Every Solaris 10 host contains a single global zone.
The global zone is both the default zone for the host 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. Some Java ES
product components, such as Sun Cluster software, can only be installed
in the global zone. A non-global zone can be thought
of as a box. One or more applications can run in this box without interacting
with the rest of the host. Each non-global zone has what appears to be its
own instance of an installed Solaris 10 operating system with configuration
and other information unique to that non-global zone. When a package is installed
in the global zone, it is, by default, propagated to all non-global zones.
In other words, the package is installed in the non-global zones as well as
in the global zone. This propagation provides non-global visibility and availability
to packages that are installed in the global zone. This propagation behavior
can optionally be suppressed when the package is added, thus restricting the
package to the global zone only. The default configuration for a non-global
zone is to share portions of the global zone's file system. Two types of non-global
zones are supported: whole root zone and sparse root zone.

A whole root zone contains a read/write copy of
the file system that exists in the global zone. When a whole root zone is
created, all packages that are installed in the global zone are made available
to the whole root zone. A package database is created and all packages are
copied onto the whole root zone, creating a dedicated and independent copy
of all files.

A sparse root zone contains a read/write copy of
only a portion of the file system that exists in the global zone, while other
file systems are mounted read-only from the global zone as loopback virtual
file systems, for example, /usr. The global administrator
selects which file systems to share with a sparse root zone at the time the
sparse root zone is created.

Note –

For Java ES, it is assumed that for sparse root zones the /opt file system is not inherited from the global zone and is, therefore,
writable.

For your zones deployment to succeed, it is crucial that you plan the
tasks and sequence of those tasks very carefully. Java ES components can potentially
be installed in any type of zone in an almost unlimited set of combinations,
and in almost any order. In some cases, the order in which Java ES product
components are installed, and the order in which non-global zones are created,
can be very important. For a full description of planning for implementing
Java ES in a Solaris zones environment, refer to the Appendix A, Java ES and Solaris 10 Zones, in Sun Java Enterprise System 5 Installation Planning Guide.

Zones Support for This Release of Java ES

The following list describes the level of zones support for this release
of Java ES:

Both whole root zones and sparse root zones are supported.

Java ES can be installed in the global zone when non-global
zones already exist.

Non-global zones can be created after Java ES is installed
in the global zone.

All shared components in a zone must be from the same release
of Java ES.

Whole root and sparse root deployments of Java ES should not
be mixed on a single computer.

The Java ES installer can install Java ES components in sparse
root zones with the following exceptions:

Sun Cluster software, Sun Cluster Geographic Edition, and
Sun Cluster Agents can only be installed in the global zone.

Message Queue can only be installed or upgraded in the global
zone, or in a whole root zone.

Shared components can only be installed or upgraded in the
global zone, or in a whole root zone.

Before Application Server can be installed into the sparse
root zone, any version of Application Server that is bundled with the operating
system must be manually removed from the global zone.

The Java ES installer controls propagation of the packages
it installs in the global zone:

Shared components are always propagated.

Message Queue and Java DB are always propagated.

All other product components are never propagated.

If you have a previous version of Java ES installed in a whole
root zone, you should not install Java ES in the global zone.

Special Situation: Installing Shared Components in
a Whole Root Zone

Installation of shared components in a whole root zone can be blocked
if specific versions of Sun Java Web Console are already installed in the
zone. This, in turn, can block installation of product components in the whole
root zone.

If you receive the following response, your host contains the defective
packages:

SUNW_PKG_ALLZONES='true'

If you want to install Java ES 5 in a whole root zone, you will first
need to upgrade the Sun Java Web Console packages in the global zone. You
have the following options:

Option 1: Run the Java ES installer in the global zone and
install only All Shared Components. This will upgrade the Sun Java Web Console
packages and fix the zones attribute. This will also install all the other
Java ES 5 shared components into the global zone and propagate them into all
non-global zones. This might not be acceptable for your situation and is not
recommended if you have a previous version of Java ES installed in a whole
root zone.

Option 2: Upgrade only the Sun Java Web Console packages in
the global zone. To do this, log into the global zone and navigate to the
Java ES 5 installation directory for Solaris. As root, do the following:cd Product/sunwebconsole ./setup The
setup script will upgrade Sun Java Web Console to version 3.0.2, which contains
the repaired zones attributes.

Note –

The Product/sunwebconsole directory
is only found in the full Java ES 5 installer, and is not available in Java
ES suite installers. If you are using a suite installer, you must download
and unzip the full Java ES 5 installer to access this directory.

After you apply one of these options, you can install Java ES 5 components
in a whole root zone.

Check to see
what installation prerequisites apply. Refer to Table 1–3.

Starting the Java ES installer in the global zone, and selecting
only shared components

Select only All Shared Components at component
selection; no other components should be selected. When shared component installation
is complete, the shared component are in the global zone and are also propagated
to all non-global zones.

Note –

For shared components that use multilingual packages, the Java
ES multilingual packages must be present in the global zone.

If Message Queue or Application Server are being used, upgrading
Message Queue in the global zone

Message Queue is often installed
during Solaris 10 installation and does not support installation into a sparse
root zone. Therefore, Message Queue must be installed in the global zone,
after which it is propagated to all non-global zones.

If Application Server is being used, removing the bundled Application
Server from the global zone

If Application Server is being used
in the deployment, the Application Server that is bundled in Solaris 10 must
be removed from the global zone. In the global zone on the host, list the
Application Server packages as follows:

pkginfo -i | grep -i "application server"

If Application Server packages are present, remove them from the global
zone. Because these packages are automatically removed from all the non-global
zones, you will need go to each sparse root zone and reinstall Application
Server.

Starting the Java ES installer in the desired sparse
root zone

At component selection, choosing the components you want

If a component cannot be installed in a sparse root zone, then it will
be unavailable for component selection.