Zones and Containers FAQ-1

Q: What is a zone?

A: A zone is a virtual operating system abstraction that provides a protected environment in which applications run. The applications are protected from each other to provide software fault isolation. To ease the labor of managing multiple applications and their environments, they co-exist within one operating system instance, and are usually managed as one entity.

Q: What is a container?

A: A zone which also uses the operating system?s resource management facility is then called a container. Many people use the two words “zone” and “container” interchangeably.

Q: What types of zones are available?

A: It is possible to create non-global zones that run the same OS as the global zone, which is the OS running on the system. It is also possible to create a non-global zone that runs a different operating environment from the global zone. The branded zone (BrandZ) framework extends the Solaris Zones infrastructure to include the creation of brands that contain alternative sets of runtime behaviors. The following types of non-global zones are available:

• native:
  The default SX CE and Solaris 10 non-global zone is the native zone. It has the same characteristics as the Solaris 10 Operating System or SX release that is running in the global zone.
  If you have configured your system with Solaris Trusted Extensions, each non-global zone is associated with a level of security, or label. Labeled zones can be configured starting with the Solaris 10 11/06 release. For more information, see Solaris Trusted Extensions Installation and Configuration.
• ipkg:
  The ipkg non-global zone is the default on the OpenSolaris release. It has the same characteristics as the OpenSolaris or SX release that is running in the global zone.
• Branded zones that run an environment different that the OS release on the system
  • The lx branded zone introduced in the SX DE and Solaris 10 8/07 releases provides a Linux environment for your applications and runs on x86 and x64 machines. For more information, visit the OpenSolaris Community: BrandZ.
  • The solaris8 and solaris9 branded zones enable you to migrate a Solaris 8 or Solaris 9 system to a Solaris 8 or Solaris 9 container on a host running the Solaris 10 8/07 Operating System or later S10 release. The solaris8 zone is an environment for Solaris 8 applications on SPARC machines. The solaris9 zone is an environment for Solaris 9 applications on SPARC machines. Now Solaris 8 Containers and Solaris 9 Containers, this product was introduced through Solaris 8 Migration Assistant 1.0, on October 22, 2007. For more information, see System Administration Guide: Solaris 8 Containers and System Administration Guide: Solaris 9 Containers. To download, go to Solaris Containers. [May 2008]
  • The Solaris 10 Container is available on OpenSolaris and SX CE as of build 127. These branded zones host Solaris 10 user environments.

Q: What is a global zone? Sparse-root zone? Whole-root zone? Local zone?

A: After installing Solaris 10 on a system, but before creating any zones, all processes run in the global zone. After you create a zone, it has processes that are associated with that zone and no other zone. Any process created by a process in a non-global zone is also associated with that non-global zone.

Any zone which is not the global zone is called a non-global zone. Some people call non-global zones simply “zones.” Others call them “local zones” but this is discouraged.

The default native zone filesystem model is called “sparse-root.” This model emphasizes efficiency at the cost of some configuration flexibility. Sparse-root zones optimize physical memory and disk space usage by sharing some directories, like /usr and /lib. Sparse-root zones have their own private file areas for directories like /etc and /var. Whole-root zones increase configuration flexibility but increase resource usage. They do not use shared filesystems for /usr, /lib, and a few others.
There is no supported way to convert an existing sparse-root zone to a whole-root zone. Creating a new zone is required.

Q: Can I create a zone which shares (“inherits”) some, but not all of /usr, /lib, /platform, /sbin?

A: The original design of Solaris Containers assumes that those four directories are either all shared (“inherited”) or all not shared. Sharing some and not others will lead to undefined and/or unpredictable behavior.

Q: How do I get zones or containers?

A: Operating systems based on the OpenSolaris code base may elect to include support for zones. Sun provides Solaris 10 and Solaris Express, each of which include complete support for Zones.

Q: What hardware can utilize zones or containers?

A: Zones and resource management are all software feature of OpenSolaris, and by extension, Solaris and other operating systems based on OpenSolaris. As software features, they do not depend upon any specific hardware platform. Any hardware that runs OpenSolaris or one of its distros, e.g. Solaris 10, will be able to have these features.

Q: Will my software run in a zone or container?

A: Most Solaris software will run unmodified in a zone, without needing to re-compile. Unprivileged software (programs that do not run as root nor with specific privileges) typically run unmodified in a zone once they can be successfully installed. Installation software must not assume that it can write into shared, read-only filesystems, e.g. /usr. This can be circumvented by adding a writable filesystem to the zone (e.g. at /usr/local) or using a whole-root zone.
However, there are a few applications which need non-default privileges to run – privileges not normally available in a zone, such as the ability to set the system?s time-of-day clock. For these situations, the feature named “configurable privileges” has been added. This feature allows the global zone administrator – the person who manages zones on a system – to assign additional, non-default privileges to a zone. The zone?s administrator can then allow individual users to use those non-default privileges.
An application that requires privileges which cannot be added to a zone may need modification to run properly in a zone.
Here are some guidelines:

• An application that accesses the network and files, and performs no other I/O, should work correctly.
• Applications which require direct access to certain devices, e.g., a disk partition, will usually work if the zone is configured correctly. However, in some cases this may increase security risks.
• Applications which require direct access to these devices must be modified to work correctly:
  • /dev/kmem
  • a network device
    1. Starting with OpenSolaris build 37 and Solaris 10 8/07, a zone can be configured as an “exclusive-IP zone” which gives it exclusive access to the NIC(s) that the zone has been assigned. Applications in such a zone can communicate directly with the NIC(s) available to the zone.
    2. Applications running in shared-IP zones should instead use one of the many IP services.

For more details, read the white paper “Bringing Your Application Into the Zone”. Note that changes have been made to privileges, IP types, and other areas used with zones since this paper was published. For current information, also see the administration guide. [November 2007]

Q: How can I test my software for use in a container?

A: See the document Qualification Best Practices for Application Support in Non-Global Zones.” [March 2006]

Q: What applications are certified to run in zones or containers?

A: Supportability of an application running in a container is evaluated by the ISV. Some software vendors treat Zones as just another feature set of Solaris, and do not feel a need to specifically certify their software to use zones. Others have specifically certified their software to use zones. Applications which have been reported to be officially supported include those in the following list. For more details see the section “Application-specific Information”

• BEA WebLogic Server 8.1 SP4
• Veritas Storage Foundation 5.0 (MP3)
• Oracle?s pricing policy regarding containers
• Veritas NetBackup 5.0 (MP4) and 5.1 (MP2)
• Sun N1 Grid Engine 6 (Update 4)
• CA Ingres
• IBM DB2 8.2
• IBM Websphere
• Oracle TimesTen
• Oracle Ebusiness Suite 11
• SAP R/3
• Veritas VCS – see “Implementing Solaris? Zones with Veritas? Cluster Server by Symantec”

Q: How can I use the Solaris ?Explorer? program to collect information on my zone(s)?

A: Explorer 5.0 can be run on Solaris 10 in a global zone. It can be used to collect information on containers (non-global zones) with the -w option.

Q: What changes have happened to zones since it was first released?

A: See the OpenSolaris project page for changes made since the initial release. [September 2006]

Q: What features are new in Solaris 10 10/08?

A: New features include the following:

1. Support has been added for using ZFS clones when cloning a zone. If the source and the target zonepaths reside on ZFS and both are in the same pool, a snapshot of the source zonepath is taken and zoneadm clone uses ZFS to clone the zone. You can still specify that a ZFS zonepath be copied instead. If neither the source nor the target zonepath is on ZFS, or if one is on ZFS and the other is not on ZFS, the clone process uses the existing copy technique. In all cases, the system copies the data from a source zonepath to a target zonepath if using a ZFS clone is not possible.
2. A new -b option to zoneadm attach has also been added. Use this option to specify official or Interim Diagnostics Relief (IDR) patches to be backed out of a zone during the attach. This option applies only to zone brands that use SVr4 packaging.

[

Q: How “big” is a zone?

A: If configured with default parameters, a zone requires about 85MB of free disk space per zone when the global zone has been installed with the “All” metacluster of Solaris packages. Additional packages installed in the global zone will require additional space in the non-global zones. SVM soft partitions can be used to divide disk slices and enforce per-zone disk space constraints. When performing capacity planning, 40MB of additional RAM per zone is suggested. Applications do not use any “extra” RAM because they are running in a zone.
A zone installed using the “full-root model” will take up as much space as the initial Solaris 10 installation, which will be more than 500MB in most cases.

Q: How many containers can one copy of Solaris have?

A: While the theoretical limit is over 8,000, the practical limit depends on:

• The amount of hardware resources used by the applications versus the amount available in the system. This includes the number and processing power of CPUs, memory size, NICs, HBAs, etc.
• What portion of the installed zones are actually in use. For example, you can create 100 zones, each ready to offer a web service, but only boot the 10 that you need this month. The unbooted zones take up disk space, but do not cause the use of any extra CPU power, RAM, or I/O.

Consider these examples which worked:

• 40 zones, each running five copies of the Apache web service, on an E250 with two 300MHz CPUs, 512MB RAM, and three hard disk drives totalling 40GB. With all zones running and a load consisting of multiple simultaneous HTTP requests to each zone, the overhead of using zones was so small it wasn’t measurable (<5%).

Q: Can each zone run a different Solaris version?

A: No. All of the zones use a single underlying kernel. The version of the kernel determines the version of every container in that domain.

Q: What types of re-configurations require a non-global zone re-boot?
A:

• Adding a device to a non-global zone.
• Binding a zone to a pool.

Q: What types of re-configurations require a complete system re-boot?

A: We are not aware of any.

Q: Can containers be clustered?

A: Yes, but not without adding additional cluster management software. As of this writing, Sun is developing extensions to its Sun Cluster software, so that Resource Groups can be placed within non-global zones. <Veritas/Symantec> has also announced support for Zones in the Veritas Cluster product.

Q: Can I use SysV shared memory between containers?

A: No. This would violate several security principles.

Q: Can a zone include multiple zones (aka “is the containment model hierarchical”)?

A: No, the model is strictly two-level: one global zones and one or more non-global zones. Only the global zone can create non-global zones, and each non-global zone must be contained within the global zone.

Q: Can I automate the process of entering system information, e.g. with sysidcfg?

A: Yes, after a zone has been installed, copy a sysidcfg(4) file to the zone’s /etc/sysidcfg before the first boot of that zone.

Q: Can some local zones be in different time zones?

A: Yes. Each non-global zone has its own copy of /etc/default/init, which contains the timezone setting. You can change the line starting with “TZ=”. The recognized names of timezones are in /usr/share/lib/zoneinfo. For example, Eastern Standard Time in the USA is defined in the file /usr/share/lib/zoneinfo/US/Eastern. To set a non-global zone’s timezone to that timezone, the line in /etc/default/init would look like this:
TZ=US/Eastern

Q: Can some non-global zones have different date and/or time settings (i.e. different clocks)?

A: Although different zones can ’be’ in different time zones, each zone gets its date and time clock from the same source. This means that the time zone setting gets applied after the current time data is obtained from the kernel.
If you would like the ability to have different clock sources per zone, please add a call record to RFE 5033497. [August 2005]

Q: Can I label my terminal windows with the name of the zone I’m logged into?

A: Yes. After logging into the zone, enter this command:

zone% /bin/echo “\033]0;Zone `/bin/zonename`\007\c”