Q: What is Solaris Zones?
Ans -: A zone is a virtual system abstraction that provides environment in which applciations run. The applications are protected from each other to provide software fault isolation. To ease the labor of manging multiple applications and their environments, they co-exits 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
o 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.
o 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]
o 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:
o /dev/kmem
o 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.
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
o 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.
o 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]
o 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:
o /dev/kmem
o 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.
.jpg)
No comments:
Post a Comment