Filter
Top Products
Version 3.1-en Solaris 10 Container Guide - 3.1 4. Best Practices Effective: 30/11/2009
4.4. Lifecycle management
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 patchadd -G.
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: 5.3.11 Using live upgrade to patch a system with
local zones ) . 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.
52