Create a whole root zone (non sparse) #blank zone create -b #template create -t SUNWblank Delete a zone forcefully zonecfg -z myzone delete -F Create a zone.cmd file from an existing zone xml zonecfg -z myzone export -f /etc/zones/myzone.cmd Create a zone form a cmd file zonecfg -z newzone -f /etc/zones/myzone.cmd zonecfg -z newzone < /etc/zones/myzone.cmd Projects/Workload Manager /etc/project /var/svc/manifest/site must make FSS active dispadmin -d FSS ps -cafe prctl -n project.cpu-shares -f -v 30 -i project proj1 prctl -n project.cpu-shares -f -v 50 -i project proj2 projmod -sK "project.cpu-shares=(priviledged,30,none)" proj1 projmod -sK "project.cpu-shares=(priviledged,50,none)" proj2 cat /etc/project prctl -n project.cpu-shares -i project proj2 newtask -p proj1 SOMECMD prstat -J projadd, projmod, projdel, projects, newtask rlimit prctl rctladm id|useradd -p ipcs -J pgrep|pkill -J -T poolbind|prctl|priocntl -i PROJECT prstat -j -J -k -T pooladm,poolcfg,poold,poolbind,poolstat /var/log/pool/poold /etc/pooladm.conf ZONES ps -efZ (for all zones by zones) zonecfg zoneadm zlogin ZONE zonename zoneadm prstat|ipcs -Z -z ps [-o ZONE] [-o ZONEID ....] pgrep|pkill|ipcrm|ppriv -z df|ifconfig -Z poolbind|priocntl|renice -i coreadm %z #added Oracle /etc/systems now automatically set in /etc/system in sol 10 (and dynamically increase as needed) projmod -sK "project.max-shm-memory=(priviledged,2g,deny)" group.dba projmod -sK "project.max-shm-memory=(priviledged,2g,deny)" oralce-proj Solaris 10 Param Oracle-lvl Sol-Def Resource-Control-Name semsys:seminfo_semmni 100 128 project.max-sem-ids semsys:seminfo_semmns 1024 obsolete semsys:seminfo_semmsl 256 512 project.max-sem-nsems shmssy:shminfo_shmmax 1/4 phys RAM project.max-shm-memory shmsys:shminfo_shmmin 1 obsolete shmsys:shminfo_shmmni 100 128 project.max-shm-ids shmsys:shminfo_shmseg 10 obsolete ================================================================================ Sparse and Whole Root Zones Sparse root zones are non-global zones that inherit in read-only mode the /lib, /platform, /sbin, and /usr directories from the global zone. Whole root zones are non-global zones that do not inherit any directories from the global zone. To create a whole root zone, you include the following lines in the zone configuration file to force non-inheritance of the default directories. # # whole-root zone (not sparse) # remove inherit-pkg-dir dir=/usr remove inherit-pkg-dir dir=/lib remove inherit-pkg-dir dir=/platform remove inherit-pkg-dir dir=/sbin Sparse Zone Configuration create set zonepath=/zone/zone1 set autoboot=true add inherit-pkg-dir set dir=/ds end add net set address=192.168.1.11 set physical=hme0 end add attr set name=comment set type=string set value="Directory Service Zone" end verify commit Sparse Zone Installation Installing the zone from zone configuration file (zone1.inf): # zonecfg -z zone1 -f ./zone1.inf # zoneadm -z zone1 install Preparing to install zone . Creating list of files to copy from the global zone. Copying <2502> files to the zone. Initializing zone product registry. Determining zone package initialization order. Initializing package <5> of <690>: percent complete: 0% ... continues until 100% complete and takes a while... Initialized <690> packages on zone. Successfully initialized zone . # zoneadm -z zone1 boot # zoneadm list -vc ID NAME STATUS PATH 0 global running / 1 zone1 running /zone/zone1 # zlogin -C -e\@ zone1 Manually answer the SysIdCfg questions to complete Solaris configuration ================================================================================ Setup a zone Zones require approx 100MB of disk. ---------------------------------------- Prep global# svcadm disable salesdb global# svcadm disable mktdb global# svcadm delete salesdb global# svcadm delete mktdb global# userdel -r oracle global# projdel ora_sales global# projdel ora_mkt global# pooladm -x global# pooladm -d ---------------------------------------- Create global# export ZONEDIR=/export/zones global# mkdir -p $ZONEDIR/mkt global# newfs /dev/md/rdsk/d200 ---------------------------------------- Configuring the Zone The zone is created based on the default template that defines resources used in a typical zone. global # zonecfg -z mkt mkt: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:mkt> create zonecfg:mkt> set zonepath=/export/zones/mkt zonecfg:mkt> set autoboot=true The virtual network interface with IP address 192.168.1.14 is configured on the hme0 interface of the global zone. zonecfg:mkt> add zonecfg:mkt:net> zonecfg:mkt:net> zonecfg:mkt:net> net set address=192.168.1.14/24 set physical=hme0 end The file system for the Oracle binaries and datafiles in the mkt zone is createdon a soft partion named d200 in the global zone. Add the following statements to the zone configuration to have the file system mounted in the zone automatically when the zone boots: zonecfg:mkt> add fs zonecfg:mkt:fs> type=ufs zonecfg:mkt:fs> set type=ufs zonecfg:mkt:fs> set special=/dev/md/dsk/d200 zonecfg:mkt:fs> set raw=/dev/md/rdsk/d200 zonecfg:mkt:fs> set dir=/u01 zonecfg:mkt:fs> end zonecfg:mkt> verify zonecfg:mkt> commit zonecfg:mkt> exit The zone configuration is now complete. The verify command verifies that the current configuration is syntactically correct. The commit command writes the in-memory configuration to stable storage. ---------------------------------------- Installing the Zone The zone is now ready to be installed on the system. global # zoneadm -z mkt install Preparing to install zone . Checking file system on device to be mounted at Creating list of files to copy from the global zone. Copying <2584> files to the zone. Initializing zone product registry. Determining zone package initialization order. Preparing to initialize <916> packages on the zone. Initialized <916> packages on zone. Zone is initialized. The file contains a log of the zone installation. ---------------------------------------- Booting the Zone The zone can be booted with the zoneadm boot command. Since this is the first time the zone is booted after installation, the standard system identification questions must be answered, and are displayed on the zone's console. The console can be accessed from the global zone using the zlogin(1M) command. global # zoneadm -z mkt boot global # zlogin -C mkt [Connected to zone 'mkt' console] SunOS Release 5.10 Version Generic 64-bit Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Hostname: mkt Loading smf(5) service descriptions: 100/100 At this point, the normal system identification process for a freshly installed Solaris OS instance is started. The output of this process is omitted here for brevity, and the configuration questions concerning the name service, time zone, etc., should be answered as appropriate for the site. After system identification is complete and the root password is set, the zone is ready for use. SunOS Release 5.10 Version Generic 64-bit Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Hostname: mkt mkt console login: To disconnect from the console use ~. (tilde dot) just like in tip(1). The zone can now be accessed over the network using the telnet(1), rlogin(1) or ssh(1) commands, just like a standard Solaris OS system. (Note that root can only login at the console unless the /etc/default/login file is updated). mkt console login: root Password: Last login: Tue Mar 22 21:55:00 on console Sun Microsystems Inc. SunOS 5.10 Generic January 2005 # df -h Filesystem size used avail capacity Mounted on / 7.9G 4.6G 3.2G 60% / /dev 7.9G 4.6G 3.2G 60% /dev /lib 7.9G 4.6G 3.2G 60% /lib /platform 7.9G 4.6G 3.2G 60% /platform /sbin 7.9G 4.6 G 3.2G 60% /sbin /u01 7.9G 8.0M 7.8G 1% /u01 /usr 7.9G 4.6G 3.2G 60% /usr proc 0 K 0K 0K 0% /proc ctfs 0K 0K 0K 0% /system/contract swap 15G 272K 15G 1% /etc/svc/volatile mnttab 0K 0K 0K 0% /etc/mnttab fd 0K 0K 0K 0% /dev/fd swap 15G 0K 15G 0% /tmp swap 15G 24K 15G 1% /var/run The /lib, /platform, /sbin, and /usr file systems are read-only loopback mounts from the global zone. This reduces the required disk space for the zone considerably, and allows the sharing of text pages, leading to more efficient use of memory. These file systems appear in the zone because they are defined in the default template used to create this zone. All other file systems are private to the zone. The /u01 file system is mounted in the zone during zone boot by zoneadmd. It is not mounted by the zone itself. Also note that the zone is unaware that the file system is in fact residing on /dev/md/dsk /d200. ---------------------------------------- Installing Oracle mkt # mkdir -p /export/home mkt # groupadd dba mkt # useradd -g dba -d /export/h ome/oracle -m -s /bin/bash oracle mkt # passwd oracle mkt # projadd -c "Oracle" user.oracle mkt # projadd -c "Oracle" -U oracle ora_mkt mkt # projmod -sK "project.max-shm-memory=(privileged,2G,deny)" ora_mkt mkt # cat /etc/project system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10:::: ora_mkt:101:Oracle:oracle::project.max-shm-memory=(privileged,2147483648,deny) user.oracle:100:Oracle:::project.max-shm-memory=(privileged,2147483648,deny) Note that the zone has its own namespace and that the user, group and project just created are therefore only visible inside the mkt zone. The Oracle software and the database are installed in /u01. In this example, the Oracle software is installed in the zone itself to create an Oracle installation idependent from anyother Oracle installations. The software could also be installed in the global one and then loopback mounted in the local zones. This would allow sharing of the binaries by multiple zones, but also create a coupling between Oracle install ations with regards to patch levels and more. This example shows how to use zone s to consolidate Oracle instances with maximum isolation from each other, so in this case the software is not shared. The installation can now be performed as described on page 91. Since /usr is mounted read-only in the zone, the default location /usr/local/bin suggested by the Oracle Installer should be changed to a writable directory in the zone, such as /opt/local/bin. ---------------------------------------- Creating the Second Zone The first zone used a directory in /export/zones in the global zone. Since this does not limit the size of the root file system of the local zone it could fill up the file system in the global zone, where /export/zones is located. To prevent a local zone from creating this problem, the zone root file system is created on a separate file system. The second zone is for the sales database and require s the following resources: A 100 MB file system for the zone root file system mounted in the global zone on /export/zones/sales. This file system is created on a Solaris Volume Manager soft partition (/dev/md/dsk/d100). A normal slice could also be used but would be quite wasteful given the limited number of slices available on a disk. To show how devices can be used in a zone, the disk slice c1t1d0s3 is exported to the zone by the global zone administrator. A UFS file system is created on this slice inside the zone. This requires that both the block and character devices for the slice be exported to the zone. Note that this is for demonstration purposes only and is not the recommended way to use UFS file systems in a zone. virtual network interface with IP address 192.168.1.15 on the hme0 interface of the global zone is also needed. global # newfs /dev/md/rdsk/d100 global # mkdir -p /export/zones/sales global # mount /dev/md/dsk/d100 /export/zones/sales global # chmod 700 /export/zones/sales ---------------------------------------- Configuring and Installing the Second Zone The steps required to configure and install this zone are the same as for the first zone, with the exception that two devices are added to the zone configuration. global # zonecfg -z sales sales: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:sales> create zonecfg:sales> set zonepath=/export/zones/sales zonecfg:sales> set autoboot=true zonecfg:sales> add net zonecfg:sales:net> set physical=hme0 zonecfg:sales:net> set address=192.168.1.15/24 zonecfg:sales:net> end zonecfg:sales> add device zonecfg:sales:device> set match=/dev/rdsk/c1t1d0s3 zonecfg:sales:device> end zonecfg:sales> add device zonecfg:sales:device> set match=/dev/dsk/c1t1d0s3 zonecfg:sales:device> end zonecfg:sales> verify zonecfg:sales> commit zonecfg:sales> exit global # zoneadm -z sales install Preparing to install zone . Creating list of files to copy from the global zone. Copying <2584> files to the zone. Initializing zone product registry. Determining zone package initialization order. Preparing to initialize <916> packages on the zone. Initialized <916> packages on zone. Zone is initialized. The file contains a log of the zone installation. ---------------------------------------- Booting the Zone The first time a zone is booted after installation, the system identification process is performed. It is possible to skip the system identification questions during the first boot of the zone by creating a sysidcfg file in the zone prior to the first boot. The location of the sysidcfg file from the global zone is /export/zone/sales/root/etc/sysidcfg. A sample sysidcfg file is shown below, and canbe customized to fit the situation. global # cat /export/zone/sales/root/etc/sysidcfg system_locale=C timezone=US/Pacific network_interface=primary { hostname=hostname terminal=xterm security_policy=NONE name_service=NIS { domain_name=yourdomain.com } root_password=sS3G0h84sqwJA To suppress the question about the NFS version 4 domain, set the NFSMAPID_DOMAIN line in the /export/zones/sales/root/etc/nfs/default file to the appropriate value for your site and create the /export/zones/sales/root/etc/.NFS4inst_state.domain file. The /dev/dsk/c1t1d0s3 and /dev/rdsk/c1t1d0s3 devices are added to the zone configuration to show how devices can be imported into a zone. Note that the only devices present in the /dev/dsk and /dev/rdsk directories are the devices that were explicitly added to the zone configuration. global # zoneadm -z sales boot global # zlogin sales sales # ls -l /dev/dsk total 0 brw-r----1 root sys 32,3 Mar 24 11:44 c1t1d0s3 sales # ls -l /dev/rdsk total 0 crw-r----1 root sys 32,3 Mar 24 11:44 c1t1d0s3 A new file system is created and added to the zone's /etc/vfstab file. sales # newfs /dev/rdsk/c1t1d0s3 sales # mkdir /u01 sales # mount /dev/dsk/c1t1d 0s3 /u01 Notice the difference beteen the /u01 file system in this zone and the /u01 file system in the mkt zone. In this zone the physical device is visible while in the mkt zone it is not visible. ---------------------------------------- Installing Oracle The installation of the Oracle software is the same as that for the mkt zone. Since the zones have completely separate namespaces, the user, group and project for Oracle must be created in this zone also. The project user.oracle should havethe resource control project.maxshm-memory added to it to allow Oracle access to the required shared memory. sales # mkdir -p /export/home/oracle sales # groupadd dba sales # useradd -g dba -m -d /export/home/oracle -s /bin/bash oracle sales # passwd oracle sales # projadd -c "Oracle" -U oracle ora_sales sales # projmod -sK "project.max-shm-memory=(privileged,2G,deny)" ora_sales sales # cat /etc/project system:0:::: user.root :1:::: noproject:2:::: default:3:::: group.staff:10:::: ora_sales:100:Oracle:oracle::project.max-shm-memory=(privileged,2147483648,deny) Use smf for the sales database for starting/stopping. Import the mainifest and enable salesdb service in the zone. ---------------------------------------- Controlling CPU Consumption of Zones The zone.cpu-shares resource control can be used to limit the CPU usage of zones with respect to other zones. This resource control is set through the zonecfg(1M) command. To give the sales zone twice the amount of CPU resources as the mkt zone, the number of zone.cpu-shares of the sales zone is set to twice the number of zone.cpu-shares of the mkt zone: global # zonecfg -z sales zonecfg:sales> add rctl zonecfg:sales:rctl> set name=zone.cpu-shares zonecfg:sales:rctl> add value (priv=privileged,limit=20,action=none) zonecfg:sales:rctl> end zonecfg:sales> exit global # zonecfg -z mkt zonecfg:mkt> add rctl zonecfg:mkt:rctl> set name=zone.cpu-shares zonecfg:mkt:rctl> add value (priv=privileged,limit=10,action=none) zonecfg:mkt:rctl> end zonecfg:mkt> exit The resource control is made active at the next zone boot. To set the zone.cpu-s hares resource control on a running zone the prctl(1) command can be used. global # prctl -n zone.cpu-shares -r -v 20 -i zone sales global # prctl -n zone.cpu-shares -r -v 10 -i zone mkt To observe processes, the prstat(1M) command has been enhanced for zones with th e -Z and -z options. The following prstat -Z output from the global zone shows processes running in the global and local zones. The bottom of the output shows a summary line for every running zone. Both zones are running eight instances of the nspin utility to show how CPU usage is controlled by the zone.cpu-shares resource control when contention arises for CPU resources. As can be seen from the output, the sales zone is given twice the amount of CPU resources, even while both zones are requesting the same amount of CPU resources from the system. global # prstat -Z PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP ... TIME CPU ZONE ... Total: 102 processes, 331 lwps, load averages: 10.89, 5.64, 3.09 To observe processes in one or more specific zones, the prstat command can be given a list of zones to observe with the -z option. The following output was taken while both zones were executing eight instances of the nspin command. Only eight of the sixteen nspin processes are shown here (those in the sales zone). Controlling CPU Consumption of Zones 73 global # prstat -z sales -a ---------------------------------------- Controlling CPU Consumption Inside Zones The zone.cpu-shares resource control determines the CPU consumption of the zone as a whole in relation to other active zones. CPU consumption inside a zone is c ontrolled by the project.cpu-shares resource control. Since zones have their own project database, the CPU consumption inside the zone can be controlled by the local zone administrator. To demonstrate this capability, two projects are added to the project database in the sales zone. The CPU shares of the projects are s et to 40 and 10, giving the first project four times more CPU resources than the second project. Each project runs four instances of the nspin utility. sales # projadd -K "project.cpu-shares=(privileged,40,none)" -U root abc sales # projadd -K "project.cpu-shares=(privileged,10,none)" -U root xyz sales # cat /etc/project system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10:::: ora_sales:100:Oracle:oracle::project.max-shm-memory=(privileged,2147483648,deny) abc:101::root::project.cpu-shares=(privileged,40,none) xyz:102::root:: project.cpu-shares=(privileged,10,none) sales # newtask -p abc sales # id -p uid=0(root) gid=1(other) projid=(abc) sales # nspin -n 4 & 29004 sales # newtask -p xyz sales # id -p uid = 0(root) gid=1(other) projid=(xyz) sales # prstat -J global # prstat -Z ---------------------------------------- Controlling CPU Consumption Inside Zones In this case, with only the sales and the mkt zones active, the sales zone is entitled to the following percentage of available CPU resources, as calculated by:zone.cpu-sharessales/ (zone.cpu-sharessales + zone.cpu-sharesmkt)= 20 / (20 + 10) * 100 = 66% This 66% is then distributed among the projects in the zone. The project abc is entitled to the following percentage of available CPU resources: project.cpu-sharesabc / (project.cpu-sharesabc + project.cpu-sharesxyz) * 66% = 40 / (40 + 10) * 66% = 53% The xyz project is entitled to 13 percent of total CPU resources (as calculated by 10 / (40 + 10) * 66% = 13%). The output from the prstat -J command in the sales zone confirms that this is the case. Note that the global zone has been omitted from the calculations for simplicity. It does, however, use some CPU resources so the numbers calculated may differ slightly from observed behavior. ---------------------------------------- Container Construction Creating the Pools The pool configuration built in Chapter 6 almost matches the design, and could be used as a basis to create the required pools. However, the pools are created from scratch in order to show all relevant steps in a single location. 1. Enable the Resource Pools facility and save the default configuration to the /etc/pooladm.conf file. (The default configuration constists of a processor set pset_default with all CPUs and a single pool pool_default.) global # pooladm -e global # pooladm -s 2. Create the sales resource pool with TS as the scheduler and the large processor set with at least two CPUs. global # poolcfg -c `create pset large (uint pset.min=2; uint pset.max=65536)' global # poolcfg -c `create pool sales (string pool.scheduler="TS")' global # poolcfg -c `associate pool sales (pset large)' 3. Create the marketing resource pool with FSS as the scheduler and the small processor set with between one and two CPUs. global # poolcfg -c `create pset small (uint pset.min=1; uint pset.max=2)' global # poolcfg -c `create pool marketing (string pool.scheduler="FSS")' global # poolcfg -c `associate pool marketing (pset small)' 4. Set the scheduler for the default pool to the Fair Share Scheduler and instantiate the pool configuration just created: global # poolcfg -c 'modify pool pool_default (string pool.scheduler="FSS")' global # pooladm -c global # poolcfg -dc info ...LOTS OF OUTPUT... ---------------------------------------- Binding Zones to Pools Currently all zones are bound to the default pool because the pool property of t he created zones has not been set, resulting in the zones being bound to the poo l with the pool.default attribute set to true. Setting the zone's pool property to the name of a resource pool binds that zone and all of its processes to that pool when the zone is booted. Note that since the sales zone is bound to a resou rce pool with the normal TS scheduler, the zone.cpu-shares resource control is n o longer applicable and is therefore removed from the zone configuration. global # zonecfg -z sales set pool=sales global # zonecfg -z sales remove rctl name=zone.cpu-shares global # zonecfg -z mkt set pool=marketing To bind a running zone to a pool without rebooting the zone, the poolbind(1M) command can be used. This dynamically rebinds the zone and its processes to a pool until the next zone boot. To have this change persist accross zone reboots, the zone's property should be set as shown above. global # poolbind -q `pgrep -z sales -x init` 28399 pool_default global # poolbind -p sales -i zoneid sales global # poolbind -q `pgrep -z sales -x init` 28399 sales global # poolbind -p global # poolbind -q `pgrep -z mkt -x init` 28545 marketing The poolbind -q `pgrep -z sales -x init` command is used to ascertain to which zone the current pool is bound by querying the binding of the init(1M) process of that zone. As can been seen, the sales zone was bound to the pool pool_default and is now bound to the sales pool. ---------------------------------------- Creating Development Zones The development environments for both databases get their own zones, enabing them to use the same user names, projects and file system paths as the production environments. The development zone for the sales database, sales_dev, is bound to the default pool and shares the pool with all processes of the global zone. To prevent the sales_dev zone from monopolizing CPU resources, its zone.cpu-shares is set to the same value as that of the global zone. This gives both zones equal access to CPU resources. When the Fair Share Scheduler is active in a resource pool, it only looks at processes in that pool. The amount of shares for the sales_dev zone is only relevant in relation to those of the global zone. global # zonecfg -z sales_dev sales_dev: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:sales_dev> create zonecfg:sales_dev> set zonepath=/export/zones/sales_dev zonecfg:sales_dev> set autoboot=true zonecfg:sales_dev> set pool=pool_default zonecfg:sales_dev> add rctl zonecfg:sales_dev:rctl> set name=zone.cpu-shares zonecfg:sales_dev:rctl> add value (priv=privileged,limit=1,action=none) zonecfg:sales_dev:rctl> end [...] global # chmod 700 /export/zones/sales_dev global # zoneadm -z sales_dev install [...] global # zoneadm -z sales_dev boot The development environment of the marketing database uses the same pool as the zone for the marketing production database. The Fair Share Scheduler is used to give preferential access to the production zone. By setting the zone.cpu-shares of the mkt zone to 50, and the zone.cpu-shares of the mkt_dev zone to 10, the production database is granted five times as much CPU resources as the development database. global # zonecfg -z mkt 'select rctl name=zone.cpu-shares; set value=(priv=privileged,limit=50,action=none);end' global # zonecfg -z mkt_dev mkt_dev: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:mkt_dev> create zonecfg:mkt_dev> set zonepath=/export/zones/mkt_dev zonecfg:mkt_dev> set autoboot=true zonecfg:mkt_dev> set pool=marketing zonecfg:mkt_dev> add rctl zonecfg:mkt_dev:rctl> set name=zone.cpu-shares zonecfg:mkt_dev:rctl> add value (priv=privileged,limit=10,action=none) zonecfg:mkt_dev:rctl> end [...] global # chmod 700 /export/zones/mkt_dev global # zoneadm -z mkt_dev install [...] global # zoneadm -z mkt_dev boot The pool bindings for the zones can be verified using the poolbind -q pid command on every zone's init(1M) process. global # poolbind -q `pgrep -z sales_dev -x init` 6718 pool_default global # poolbind -q `pgrep -z sales -x init` 28399 sales global # poolbind -q `pgrep -z mkt -x init` 28545 marketing global # poolbind -q `pgrep -z mkt_dev -x init` 6579 marketing global # poolbind -q `pgrep -z global -x init` 1 pool_default ---------------------------------------- Creating Development Users and Projects global # zlogin mkt_dev mkt_dev # mkdir -p /export/home mkt_dev # groupadd dba m mkt_dev # useradd -g dba -m -d /export/home/oracle -s /bin/bash oracle mkt_dev # projadd -U oracle ora_mkt mkt_dev # projmod -sK "project.max-shm-memory=(privileged,2G,deny)" ora_mkt mkt_dev # projmod -sK "project.cpu-shares=(privileged,100,none)" ora_mkt mkt_dev # useradd -m -d /export/home/dev1 -s /bin/bash dev1 mkt_dev # useradd -m -d /export/home/dev2 -s /bin/bash dev2 mkt_dev # projadd user.dev1 mkt_dev # projadd user.dev2 mkt_dev # projmod -sK "project.cpu-shares=(privileged,10,none)" user.dev1 mkt_dev # projmod -sK "project.cpu-shares=(privileged,1 0,none)" user.dev2 [Oracle installation omitted for brevity...] global # zlogin sales_dev sales_dev # mkdir -p /export/home sales_dev # groupadd dba sales_dev # useradd -g dba -m -d /export/home/oracle -s /bin/bash oracle sales_dev # projadd -U oracle ora_sales sales_dev # projmod -sK "project.max-shm-memory=(privileged,2G,deny)" ora_sales sales_dev # projmod -sK "project.cpu-shares=(privileged,100,none)" ora_sales sales_dev # useradd -m -d /export/home/dev1 -s /bin/bash dev1 sales_dev # useradd -m -d /export/home/dev2 -s /bin/bash dev2 sales_dev # projadd user.dev1 sales_dev # projadd user.dev2 sales_dev # projmod -sK "project.cpu-shares=(privileged,10,none)" user.dev1 sales_dev # projmod -sK "project.cpu-shares=(privileged,10,none)" user.dev2 [Oracle installation omitted for brevity...] ---------------------------------------- Verifying the Configuration global # prstat -Z global # poolstat -r pset 5 sales_dev # prstat -J ---------------------------------------- References Solaris 10 Resource Manager Developer's Guide. 817-1975-10. To access this book online, go to http://docs.sun.com. System Administration Guide:Basic Administration. 817-1985. To access this book online, go to http://docs.sun.com. System Administration Guide:Network Services. 816-4555. To access this book online, go to http://docs.sun.com. System Administration Guide:Solaris Containers -- Resource Management and Solari s Zones. 817-1592. To access this book online, go to http://docs.sun.com. Solaris Containers: Server Virtualization and Manageability, Technical White Paper, Sun Microsystems, September, 2004. This white paper is available for download at http://www.sun.com/software/solaris/whitepapers.xml. ================================================================================ Running SAP on Solaris 10 in a global or local zone: Checking resource control settings Changing and setting OS or process parameters for an SAP system on Solaris has never been easier and more flexible than with Solaris 10: Instead of having to reboot your server after changing OS parameters in file /etc/system, just set up projects, assign users to those projects, and (re)start the processes for these users. Or even change the settings for running processes! Here's how it all works: According to SAP note 724713 and Sun Info Doc 88934, four resource controls have to be set for SAP systems running on Solaris 10 (instead of more than 10 for previous Solaris releases). Only one parameter has to remain in /etc/system: set rlim_fd_cur=8192 Next step is to decide what you want to use your projects for: Do you want to set limits for your database and your application instance(s) separately? Do you want to configure processor sets for each of your projects? Or do you want to limit usage of physical memory per project? You can find explanations and examples for all of the above in the System Administration Guide: Solaris Containers-Resource Management and Solaris Zones. Let's assume you would like to do a quick start and just use the simplest possible configuration (one project for database and SAP application instance), and let's assume your SAP system has the id "DEV". Then, the following commands would set your resource controls appropriately: $ projadd -p 101 -c "SAP System DEV" -U devadm,oradev \ -K "project.max-sem-ids=(priv,1024,deny)" \ -K "process.max-sem-nsems=(priv,2048,deny)" \ -K "project.max-shm-ids=(priv,256,deny)" \ -K "project.max-shm-memory=(priv,18446744073709551615,deny)" \ DEV Next step is to add those two users to your /etc/user_attr file so that they get a default project assigned: $ ksh (no need to switch to ksh if you like the "wrong apostrophes" better than $() ;-) ) $ cp -pi /etc/user_attr /etc/user_attr.$(date +%Y%m%d-%H%M%S) (Backing up or printing system configuration files before changing them manually is always a good idea) $ cat >> /etc/user_attr devadm::::project=DEV oradev::::project=DEV d Done. Now check if the settings are OK: $ projects -d devadm DEV $ projects -l $(projects -d devadm) DEV projid : 101 comment: "SAP System DEV" users : devadm oradev groups : (none) attribs: process.max-sem-nsems=(priv,2048,deny) project.max-sem-ids=(priv,1024,deny) project.max-shm-ids=(priv,256,deny) project.max-shm-memory=(priv,18446744073709551615,deny) Everything's fine, so now you can start your SAP installation! (Before you ask: I always add the required groups and users by using groupadd and useradd before starting the SAP installer.) ================================================================================