Print-friendly Version

The Zones Update on Attach Feature and Patching in the Solaris 10 OS

Enda O'Connor, June 2009

Introduction

Since the Solaris 10 5/08 Operating System, system administrators have had the ability to detach and attach zones, that is, detach a zone from one system and attach it to another. Some restrictions applied with the initial functionality, in that the source and destination system where the non-global zone was being attached had to have the same software level in terms of package versions, patch levels, and architecture. In other words you couldn't move a zone from a sun4v system to a sun4u system or from a prior Solaris release to the current Solaris update release.

In the Solaris 10 10/08 release, new functionality was provided by way of the "update on attach" command, the -u argument to zoneadm attach.

This article describes the update on attach functionality and covers the following topics:

• Criteria for Determining Which Packages Are Updated
• Update on Attach Versus Regular Upgrade
• Patching and Zone Update on Attach
• Whole Root Zone Versus Sparse Root Zone
• Presence of Interim Diagnostic Relief (IDR) Patches and Special Patches
• Steps for Running Update on Attach
• For More Information

Criteria for Determining Which Packages Are Updated

When you use update on attach, the zone being attached is updated to the same software level as the global zone according to the following logic, which determines which packages are updated:

1. If a package in the non-global zone has the setting SUNW_PKG_ALLZONES=true, it is selected for update.
2. If a package delivers bits to an inherited package directory, it is selected for update. ("Inherited package directory" refers to a directory that is inherited by the non-global zone from the global zone. A sparse zone inherits /usr, /lib, /platform, and /sbin by default. Any directories added through the zonecfg command's add inherit-pkg-dir subcommand are inherited package directories.)
3. Any package depended upon by either number 1 or 2 above also gets updated, regardless of its SUNW_PKG_ALLZONES setting and regardless of whether it delivers bits to an inherited package directory.

Once a package is selected for update, the same process that installed the package when the zone was initially installed is used to do the following:

• Remove the package from the non-global zone being updated
• Install the spooled package from the global zone where the attach is occurring to the non-global zone being attached

In the case of, say, updating SUNWcsr, the /var/sadm/pkg/SUNWcsr/save/pspool/SUNWcsr/ directory in the global zone is used to provision the updated SUNWcsr package in the non-global zone being attached. This directory is what is used to provision a new non-global zone's SUNWcsr package initially during zoneadm install.

So, an example of number 3 above would be that when package A has SUNW_PKG_ALLZONES=true, it is selected for update. Package A depends on package B. Package B does not have SUNW_PKG_ALLZONES=true and delivers to the /etc directory (so it does not meet the criteria for either number 1 or 2 above). But because package A depends on package B, package B also gets selected for update.

The selection criteria are important when considering the inherited package directories that the non-global zone uses. In the case of a whole root non-global zone, there are no inherited package directories. Therefore, fewer packages get selected for update than for a sparse zone running the same software level.

It is also worth considering that any package in the global zone that has SUNW_PKG_THISZONE=true is automatically skipped, that is, if the package exists in the non-global zone, it is not updated.

Update on Attach Versus Regular Upgrade

Before continuing, it is good to understand the difference between doing a standard upgrade using any of the supported upgrade mechanisms and using update on attach. When doing a standard upgrade, all native Solaris non-global zones are upgraded, that is, they receive any new packages and features that are being delivered as part of the upgrade, obsolete packages are removed, and the non-global zones and the global zone will be at the same software level with respect to patches and package versions that are delivered in the update release.

In other words, the update image gets applied to the global zone and all non-global zones. No dependency checks are performed in relation to the global zone and non-global zones during an upgrade, and all the packages that are part of the image are laid down across all the zones, including the global zone.

In contrast, when you use update on attach, a software inventory is taken of both the global zone and the non-global zone being updated. Then, using the three criteria described previously, zoneadm determines what packages to update in the non-global zone.

So if you detach all the non-global zones from a system and then do a standard upgrade to a later update release on the global zone, and then you use update on attach with the non-global zones, the results are different than if you do a standard upgrade of the system as a whole with the zones attached at the time of upgrade. Any new packages delivered in the update are not propagated to the attached non-global zones unless at least one of the following is true:

• The packages satisfy SUNW_PKG_ALLZONES=true.
• The packages deliver bits to an inherited package directory.
• A package that satisfies ALLZONES=true, or is delivered to an inherited package directory, or both depends on the new package.

Any obsolete packages are not removed unless they satisfy ALLZONES=true or they are delivered to an inherited package directory.

The main intended use for update on attach is to let users migrate non-global zones from one system to another with minimal user interaction. Prior to the Solaris 10 10/08 release, users had to ensure that the non-global zone being attached was at exactly the same software level with respect to the system software as the system where the non-global zone was being attached. With zones update on attach, system administrators can now attach a zone that has a lower patch level and the zone is updated automatically to the same level, with respect to patches, as the global zone it is being attached to. Users can now also migrate a non-global zone from a sun4v system to a sun4u system or from a sun4u system to a sun4v system.

One of the main uses of update on attach is to allow quick, easy migration of Solaris Containers between differing systems. (A container is a combination of a non-global zone and resource controls.) An example usage would be if a Sun Fire T2000 server is running five containers, with each container running a particular database, and one of these databases grows more than expected over time, which might lead to performance problems as system resources become exhausted. Without the ability to migrate the affected container to a more high-performance system, the end user would have to replicate the container, its software, and the software configuration on another system, and then eventually make the switch from the old container to the new container. But with zone migration, this task becomes much easier, because the affected container can now be moved along with its database, its configuration, and the associated workload to a new system, thereby increasing the available resources for both this container and the four remaining containers on the old system.

Patching and Zone Update on Attach

A lot of interest has arisen about the ability to use update on attach to bring non-global zones up to the same patch level as the global zone. Here is an example: Before applying a patch bundle, a sys admin could detach all the non-global zones, then apply the patch bundle to the global zone, and then, after the bundle has been applied and the system has been rebooted, use the zone zoneadm -z <zonename> attach -u command to bring the non-global zones back to the same patch level as the global zone.

The main reason for doing this is that update on attach is far quicker than patching zones serially. Also, multiple zoneadm attach commands can be run. The main problem is that depending on the patches that got applied in the global zone and the configuration of the non-global zones in relation to inherited package directories, the outcome from using update on attach might be different than if you applied the patches to the global and the non-global zones using patchadd with all non-global zones attached.

An example, even though it is slightly contrived, might help to explain how this can occur. If one of the non-global zones was a whole root zone, and one of the patches being applied was patching Mozilla Firefox, say, patch 125539-05, then the global zone would have 125539-05 applied, but zone update on attach would not update SUNWfirefox in the non-global zone. So patch 125539-05 would not be applied in the non-global zone.

If, instead, you use patchadd with the zone attached, 125539-05 would be applied to the non-global zone by patchadd. This is due to the fact that migrating a zone involves different planning than upgrading a zone. Deciding whether to upgrade application-level software (of which SUNWfirefox is an example) is something that only the sys admin can decide. Therefore, zone update on attach will not update application-level software, leaving such decisions to the system administrator. A traditional upgrade on the other hand upgrades all the software that is on the media.

Also, in a whole root non-global zone, unless SUNWupdatemgru is installed, the packages that the patch utilities patch delivers to are not updated. This means that, in effect, unless SUNWupdatemgru is installed in the whole root non-global zone, the zone might end up out of sync with the global zone with respect to the patch utilities patch 110254/119255 if a later revision is installed in the global zone.

This is because 119254/119255 patches the SUNWswmt, SUNWinstall-patch-utils-root, and SUNWpkgcmdsu packages, all of which satisfy SUNW_PKG_ALLZONES=false. Also, because there are no inherited package directories in a whole root zone, these packages are not selected for update unless SUNWupdatemgru is installed, because SUNWupdatemgru satisfies SUNW_PKG_ALLZONES=true and depends on SUNWswmt, which in turn depends on SUNWinstall-patch-utils-root and SUNWpkgcmds.

Therefore, SUNWswmt, SUNWinstall-patch-utils-root, and SUNWpkgcmds all are selected, because SUNWupdatemgru depends on SUNWswmt, and it in turn depends on SUNWinstall-patch-utils-root and SUNWpkgcmds.

Normally, SUNWupdatemgru is in the same install metacluster as SUNWzoner and SUNWzoneu, so it is installed in any non-global zones. But if the system was provisioned by installing the minimum metacluster and then the zones packages were added, the patch utilities packages in any whole root non-global zones are not updated on attach, because SUNWupdatemgru is not installed.

All packages that are updated are first removed from the non-global zone, and then they are reinstalled from the global zone using the same functionality that was used to install the zone initially. (This functionality is scheduled to change in a later update release due to CR 6818813. After CR 6818813 is fixed, any package selected for update, whose version matches that of the package installed in the global zone, will not be removed, and the package on the non-global zone will simply be replaced. This should speed up the performance of update on attach as well.)

So, the same functionality that is used to install zones initially is also used by update on attach. In the case of packages that are updated, all the patch package undo.Z packages for the package are inherited from the global zone into the non-global zone being attached. If the global zone has been heavily patched, this can cause the non-global zone's space footprint to increase significantly in cases where the non-global zone being attached was detached from a system that had little or no patches applied.

If an end user just used patchadd to patch both the global and all non-global zones, then undo.Z is generated within each non-global zone being patched, and it contains only the files that were actually replaced within that non-global zone. In the case of a sparse zone, this means that the undo.Z created by patchadd does not contain any files that reside on /lib, /platform, /bin, or /sbin. So it is smaller in size than the undo.Z from the global zone that is inherited by using zone update on attach functionality.

Whole Root Zone Versus Sparse Root Zone

Using update on attach to update a sparse root zone as opposed to a whole root zone (where both zones were provisioned at the same time on the same system, so they have the same package and patch level) results in both zones being updated differently with respect to the number of packages chosen for update. So, in a sparse root zone created on the Solaris 10 5/08 OS and updated to the Solaris 10 10/08 level, 505 packages are selected to be updated, whereas in a whole root zone, 311 are selected to be updated.

So before considering using zone update on attach to speed up patching, you need to be aware of the differences between using update on attach to bring a non-global zone up to the same patch level as the global zone versus just using patchadd with all the non-global zones attached and available for patching.

Presence of Interim Diagnostic Relief (IDR) Patches and Special Patches

Also the presence of so called "special patches," which are patches used only in the construction of the Solaris 10 update images and are never released, must be resolved. Special patches are addressed by CR 6743776 in the currently released patch 140197. A permanent solution to the handling of these special patches is addressed in CR 6791625, which is delivered in the Solaris 10 5/09 OS by patch 139555-08.

Steps for Running Update on Attach

1. On the source system, run zoneadm -z <zonename> detach. (Note: Detach functionality was introduced in the Solaris 10 5/08 OS.)

2. Move the zonepath to the destination system.

3. If the destination global zone is not at kernel patch level 139555 (Solaris 5/09 or higher update level), then run the following command to force the regeneration of the source non-global zones packages. The relevant CR is 6685069.

#rm <zonepath>/SUNWdetached.xml

4. Reconfigure the zone using zonecfg on the target system.

5. Finally, run this command:

#zoneadm -z <zonename> attach -u

Please see How to Migrate A Non-Global Zone for a full description of the steps that are required to migrate a zone.

Error reporting in Solaris 10 5/09 has also been improved. For a package that was considered to be downgraded (that is, the version of the package in the non-global zone being attached was higher than the source global zone where it was being attached), prior releases reported every instance, one by one. In other words, zoneadm attach -u would report only one error at a time. In the Solaris 10 5/09 OS, the first zoneadm attach -u reports all errors at one time.

For More Information

Here are some additional resources:

• Patching Center on BigAdmin
• BigAdmin Resource Collection: Patches and Releases
• Gerry Haskins' Patch Corner blog
• Sun download site
• Sun training courses at http://www.sun.com/training/
• Forums, such as Sun forums and BigAdmin Discussions
• Product documentation at http://docs.sun.com and the Documentation Center
• Sun wikis:
  • Sun BluePrints wiki, which provides documents (registration required) such as Patching Mirrored Systems with the Solaris Live Upgrade Software
  • BigAdmin wiki
• Support:
  • Sun resources:
    • Register your Sun gear
    • Services
    • SunSolve Online
  • Community system administration experts
• Events of interest to users of Sun products:
  • Worldwide Developer Events and Sun Tech Days
  • Current Events

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.