Zones and Containers FAQ-3
Q: How can I prevent one container from consuming all of the CPU power?
A: Use the resource management features of Containers. This requires using some combination of the Fair Share Scheduler, CPU caps, assigned (’dedicated’) CPUs, and/or [Dynamic] Resource Pools features.
Q: What is the resource granularity for CPU assignment to a container?
A: Fair Share Scheduler: Arbitrary. FSS guarantees a minimum amount of CPU utilization, so it doesn’t waste CPU cycles. Excessive CPU use is only prevented if there is contention for CPU resources. Minima are specified by “shares” and enforced by the Fair Share Scheduler. For example, CPU share assignments could be 1, 1000, 999, resulting in utilization minima of 0.05%, 50%, and (practically speaking) 50%.
CPU Cap: number of CPUs, in hundredths of a CPU. One zone can be capped at 4.01 CPUs, and another can be capped at 4.02 CPUs. Dedicated CPU: CPU range, in integer number of CPUs. On an x86 system, Solaris considers every CPU core to be a “CPU.” On SPARC CMT systems, every hardware thread is a “CPU” so a four-socket T5440 has 256 “CPUs.” On other SPARC systems, every CPU core is a “CPU.”
Q: How can I limit (cap) the CPU usage of an application?
A: In OpenSolaris, and starting with Solaris 10 5/08, use the capped-cpu resource type. In OpenSolaris and starting with Solaris 10 8/07, you can use the dedicated-cpu resource type to automatically create a temporary pool when the zone boots..
Alternatively, you can create a processor set with one or more CPUs and bind it to a resource pool. Then create a zone and bind it to the same resource pool. Run the application in that zone. The application will only “see” that set of processors. For more information,
Q: How can I limit the memory used by a container?
A: You can use the Resource Capping Daemon (rcapd) for all releases. In OpenSolaris, and starting with Solaris 10 8/07, you can use the capped-memory resource to set limits for physical, swap, and locked memory. Determine values for this resource if you plan to cap memory for the zone by using rcapd from the global zone. The physical property of the capped-memory resource is used by rcapd as the max-rss value for the zone.
Q: Can I dynamically change the quantity of a resource (CPU, memory, network bandwidth) assigned to a container?
A: To change the number of CPU shares associated with a container without re-booting it, use the prctl command, e.g.
prctl -n zone.cpu-shares -r -v $SHARES `pgrep -z $ZONENAME init`
where $SHARES is the new number of shares and $ZONENAME is the name of the zone.
In OpenSolaris and Solaris 10 (starting with 5/08) similar methods can be used to change the CPU cap, RAM cap, VM cap and shared memory cap.
Q: Can swap space usage be managed?
A: The entire swap partition is treated as a single global resource to processes running in both global and non-global zones. Before Solaris 10 8/07, you couldn’t limit the amount of swap used by a zone on a per-zone basis. You can globally limit the size of the swap-based filesystems (e.g. /tmp) by using the “size” mount option in the container’s /etc/vfstab file, e.g. “size=200m”. This allows you to decrease the effect of many and/or large files created in /tmp.
Starting with Solaris 10 8/07, you can use the capped-memory resource to cap the amount of virtual memory (VM) that a zone uses. This can also be set dynamically with the resource control zone.max-swap.
[January 2009]
Q: Can I limit the network bandwidth used by a zone?
A: Yes, use the IPQoS features in Solaris 10. You must manage this from the global zone for the containers.
Q: Do containers use up alot of CPU power?
A: CPU overhead of containers is hardly measurable (i.e. <1%) for a few zones or even dozens of zones, depending somewhat on the applications.
Q: Can the share value for a running project or zone be changed?
A: Yes. Here is an example:
prctl -n project.cpu-shares -v 10 -r -i project group.staff
The prctl utility allows the examination and modification of the resource controls associated with an active process, task or project on the system. It allows access to the basic and privileged limits on the specified entity.
-n specifies the name of the resource to get or set
-r specifies a replace operation
-v specifies the new value for the resource
-i specifies the owning process, task or project of the resource.
Q: Can I bind a zone to a pool?
A: Yes, but in OpenSolaris and Solaris 10 8/07 and later, it’s much easier to use the ’dedicated-cpus’ feature.
To bind a zone’s processes to a pool, first create the pool, then use zonecfg(1M) to bind a zone to it.
- Enable resource pools on your system using either svcadm or pooladm -e.
2. Use pooladm -s to create the pool configuration.
3. Use pooladm -c to commit the configuration at /etc/pooladm.conf.
4. Use poolcfg -c to modify the configuration.
poolcfg -c ’create pset pset_zone (uint pset.min = 3; uint pset.max = 3)’
poolcfg -c ’create pool pool_zone (string pool.scheduler=”FSS”)’
poolcfg -c ’associate pool pool_zone (pset pset_zone)’
5. Use pooladm -c to commit the configuration at /etc/pooladm.conf.
The command to perform the binding, from the global zone, would be:
zonecfg -z zone1 set pool=pool_zone
If the zone was running, you must re-boot it for the binding to take effect, unless you also dynamically assign the zone to the pool, as described in the question “Can projects/zones be reassigned to a different resource pool while they are running?”. [January 2009]
Q: Can projects/zones be reassigned to a different resource pool while they are running?
A: Yes. Here is an example:
poolbind -p web_app -i zoneid myzone
The poolbind command binds zones, projects, tasks and processes to a pool.
-p is the name of the pool to bind
-i specifies the process id, zone id, task id or project id to be bound to the pool.
Q: Can you move processors between processor sets while the system is running?
A: Yes, you can. Here is the command(s) you would use:
- If you don’t care which CPUs you move from a processor set the command would be:
poolcfg -dc “transfer 2 from pset pset1 to pset2”
which will move any two processors from pset1 to pset2
-d operate directly on the kernel state
-c this signifies the command
If you want to move a specific CPU(s) here is the command:
poolcfg -dc “transfer to pset pset2 (CPU 0, CPU 1)”
which will move CPUs 0 and 1 to pset2.
Q: How can I prevent one zone from using all the swap space by filling up /tmp?
A: For manual mounts, use the option “-o size=sz” where sz is the size limit you want. Ending the size in ’k’ means kilobytes, ending it in ’m’ means megabytes. Example: “-o size=500m”. This option can also be added into /etc/vfstab. For more details, view the man pages for mount_tmpfs(1M) and vfstab(4).
With Solaris 10 8/07, you can use the resource control, zone.max-swap. (The swap property of the capped-memory resource is the preferred way to set this control.)
Also, note that RFE 1177209 will give the global zone administrator the ability to control the amount of swap space used by one zone.
Q: Do I need to set a locked memory cap for a zone? If so, what value should I set?
A: A locked memory cap in a zone can be set using the zonecfg capped-memory resource. Applications generally do not lock significant amounts of memory, but you might decide to set locked memory if the zone’s applications are known to lock memory.
If the zone administrator is less than trusted or if DOS exploits are of concern, you can also consider setting the locked memory cap to 10% of the system’s physical memory or to the zone’s physical memory cap.
[November 2008]
Section 4: System Administration
Q: What software can manage zones?
A: Here are just a few of the software tools – some free, some not free – which will help you manage Solaris Zones:
- SunMC (Sun Management Center) GUI
- WebMin GUI has a Solaris Zones module
- Xone Control GUI
- The Zone Manager Command
- Zonestat command reports on resource usage and caps
[April 2009]
A: First gather some information, then use the Solaris Container Manager GUI or the commands shown below. This is the simplest possible creation of a zone that has network access. You will need this information (example values in parentheses:
- Name that you choose for the zone (my-zone)
2. Hostname that choose for the zone (my-zone)
3. Name of the directory in the global zone where all of the zone’s operating system files will be (/zones/zone_roots/my-zone)
4. IP address of the zone (10.1.1.1)
5. Name of the network device that the zone should use (hme0)
Using the sample information in the appropriate commands, which will take about 10 minutes on a small system with a new installation of OpenSolaris or Solaris 10:
global# zonecfg -z my-zone
zonecfg:my-zone> create
zonecfg:my-zone> set zonepath=/zones/zone_roots/my-zone
zonecfg:my-zone> add net
zonecfg:my-zone:net> set address=10.1.1.1
zonecfg:my-zone:net> set physical=hm0
zonecfg:my-zone:net> end
zonecfg:my-zone> commit
zonecfg:my-zone> exit
global# zoneadm -z my-zone install
global# zoneadm -z my-zone boot
A: Use these commands, substituting the correct names for <bracketed> text.
global# zoneadm -z <zonename> uninstall
global# zonecfg -z <zonename> delete
Q: Is the maximum number of exclusive-IP zones limited to the number of physical ethernet ports?
A: No, if you use VLANs you can have one per VLAN per port. To use the same base ’bge0’ for multiple dhcp zones, in the case of VLANs you would assign bge1000 to zoneA, bge2000 to zoneB, etc. The VNIC component of Crossbow allows multiple virtual NICs on a port without any VLANs.
Q: Are there any recent changes for exclusive-IP zones in OpenSolaris?
A: Prior to build 83, the data-link used with exclusive-IP zones must be GLDv3. Note that there is a patch [patch ID 118777-12] that allows the legacy ce device to be used with exclusive-IP zones with build 80-82. In OpenSolaris build 83 and later, the data-link used with exclusive-IP zones need not be GLDv3 since the Nemo unification provides a way to present legacy device drivers as GLDv3 using a shim module. Hence, no patch to ce is necessary.[May 2008]
Q: Is it still necessary to set the NFSv4 domain parameter?
A: The new keyword nfs4_domain was added to the sysidcfg file to allow “no-hands” reboot in SX CE and Solaris 10 8/07.
A: Note that a zones parallel patching enhancement to the standard Solaris 10 patch utilities increases the patching tools performance on systems with multiple zones by allowing parallel patching of the non-global zones. See “Zones Parallel Patching” on the Solaris Containers (Zones) BigAdmin System Administration Portal.
Q: Can each container be a different Solaris patch level, so I can test patches in a “test” container before applying them to a “production” container?
A: There are two parts to the answer: 1) There is only one kernel running on the system, so all zones must be at the same patch level with respect to the kernel and core system components. Such patches can only be applied from the global zone, and they affect the global and all local zones equally. The KU is an example of such a patch.
2) Middleware such as Java Enterprise System can be patched on a per-zone basis. If the software can be installed in the local zone then it must be patchable from the local zone as well, regardless of the zone type, whole-root or sparse-root.
Q: Is there a way to correlate audit records from multiple containers?
A: Yes, the global zone sees all audit records. Each non-global zone only sees its own audit records.
Q: Can I add packages to just the global zone (for example, SRS netConnect)?
A: Yes, use pgkadd -G. Note that if the SUNW_PKG_THISZONE package parameter is set to true, you do not have to use the -G option. [September 2006]
Q: Can I add a package to one non-global zone without adding it to the global zone?
A: That depends on the settings used when the package was created. .
Q: What commands don’t work, or behave differently, inside a zone?
A: Most Unix commands and programs work correctly, without alteration or re-compilation. >>Project crossbow.CrossbowBeta]]
However, the implementation of the security isolation boundary limits the functionality of several system calls and libraries. That, in turn, limits the functionality of several system commands. In other words, some Solaris commands behave differently when run inside a zone, or do not work at all inside a zone.
See the sections 6.1 System Calls, 6.2 Library Functions, 6.3 Commands, and 6.4 Device and Interface Special Files in http://www.sun.com/bigadmin/features/articles/zones_partition.html#limitations.
For information on the status of privileges in zones, see Table 26-1 Status of Privileges in Zones
[November 2006]
Q: Do zones boot automatically, or must I boot each one manually every time the system (re)boots?
A: The zones autoboot property determines whether the zone is booted when the system boots. The global zone adminstrator can set the autoboot property to “true” or “false.” The zones service svc:/system/zones:default must also be enabled. [September 2006]
Q: Should I halt a system’s zones before applying patches?
A: There is no need to do this. In fact, the package and patch tools will perform their operations on all zones that are running, as well as all zones that are not currently running but are capable of being booted (e.g. they are at least in the “installed” state). The running zones are operated on first, and then for each zone that is not running but can be booted, the zone is booted, the operation is performed, and the zone is then halted.
Q: Where does a zone’s syslog output go?
A: By default the syslog output from a zone goes only into the zone’s syslog file. If you would like the output to also appear in the global zone’s log files, configure the non-global zone’s loghost to be the global zone.
Q: I removed a device from a zone, but it’s still there. Why, and how do I get rid of it?
A: This is bug 4963368. The current (Feb 2005) workaround is: after using zonecfg to remove the device, manually remove the corresponding entry in {ZONEPATH}/dev.
If you’re running Solaris Express, this bug is corrected in builds 46 and higher. If you are running Solaris 10, this bug is corrected in Solaris 10 8/07.
Leave a Reply