Sun Microsystems 10 用户手册

  Solaris 10 Container Guide - 3.1   4. Best Practices 

Effective: 30/11/2009

4.4.1. Patching a system with local zones
[dd/ug] In a Solaris system with native zones, the local zones always have the same patch status as 
in the global zone. This is independent of whether the local zone is a sparse root zone or a whole root 
zone.   Therefore,   patches   on   this   type   of   system   are   installed   in   the   global   zone   and   thereby 
automatically in all local zones.

•

Contrary to procedures prior to Solaris 10 10/08, zones can be patched, while not booted.

•

The patching process requires that the zones to be patched are in "installed" status.

•

The configured file systems (per  zonecfg  and /etc/vfstab  of the local zone) must be 
mountable through the global zone.

•

For patching, the configured file systems of a zone are mounted, the patch is installed and the 
file systems are unmounted again. This process runs separately for each patch.

When installing a patch cluster, this procedure is performed successively for all patches and zones. 
Therefore, patching can take several hours or days if there are many patches to be installed (e.g. 
patch clusters) and many zones present.

There are a variety of considerations as to how the expenditure of time to patch many zones and thus 
the downtime of zones can be reduced:

1. The patch utilities have been optimized such that simultaneous patching of many local zones 

is possible. These utilities were made available in June 2009 by patches 119254-66 (SPARC) 
and 119255-66 (x86).
(see also 

http://blogs.sun.com/patch/entry/zones_parallel_patching_feature_now

)

This functionality has been integrated into Solaris 10 10/09.

The time gained by using these new utilities is enormous. Jeff Victor has done some research 
on this in his blog. 

http://blogs.sun.com/JeffV/entry/patching_zones_goes_zoomUtilities

To use the mechanism, it is mandatory that the readme.txt of the patch is observed as the 
number of zones to be patched in parallel must be configured first (see /etc/patch/pdo.conf). 
From it follows that the number of zones to be patched in parallel depends on the number of 
CPUs available in the system.(max. number of parallel zones to be patched = number CPU * 
1.5) Older tools for simultaneous patching of zones should not be used anymore.

2. So as not to affect the currently running system by patching procedures, a separate patch 

server can also be used. In this procedure the current zones are duplicated and the copies of 
the zones are moved to a patch server via  zoneadm   detach  /  zoneadm   attach. 
The patches are then installed on this server. Next, the zones are moved to a server that 
already contains the current patches in the global zone.

Comments:

•

In general, the goal is to ensure that local zones contain the same patch status of the operating 
system as the global zone. This is mandatory for system libraries.

•

Using a different patch status in zones can be considered for the application software used only.

•

If patches are to be installed in a certain zone only, e.g. in whole root zones, to test patches, 
then patches can be installed in a zone with 

.

The following URL contains further information and recommendations on the topic of patching: 

http://

www.sun.com/bigadmin/hubs/documentation/howto/patch.jsp

Further information on the topic of patching can also be found here (

http://blogs.sun.com/patch/

) and 

here (

http://www.sun.com/bigadmin/features/articles/patch_management.jsp

).

4.4.2. Patching with live upgrade
[ug/dd] Starting with Solaris 10 8/07, live upgrade can also be applied to patching on zones if the 
zonepath is located on ZFS. (See also Cookbook: 

. To do so, a copy of the active Solaris boot environment with all its local zones installed 

is   created   through  lucreate(1M).  Then   the   patches   are   installed   into   this   copy   using 
luupgrade  -t. A luactivate(1M) activates the boot environment, which is active after the 
next   reboot.   By   using  live   upgrade,   the   downtime   of   services   during   patching   can   be  drastically 
reduced since the patch process runs parallel to the system in production. Downtime is required only 
to activate the updated boot environment by rebooting. It must be taken into account that live upgrade 
generates an I/O-load that must in addition be made available by the server and the disk system 
during the runtime of lucreate and luupgrade.