Sun Microsystems 10 manual Lifecycle management, Patching a system with local zones

Version 3.1-enSolaris 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