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.

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.