Your search did not match any results.
We suggest you try the following to help find what you’re looking for:
Enda O'Connor, June 2009
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
This article describes the update on attach functionality and covers the following topics:
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:
SUNW_PKG_ALLZONES=true, it is selected for update.
/sbinby default. Any directories added through the
add inherit-pkg-dirsubcommand are inherited package directories.)
SUNW_PKG_ALLZONESsetting 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:
In the case of, say, updating
/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
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.
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:
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.
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
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
SUNW_PKG_ALLZONES=true and depends on
SUNWswmt, which in turn depends on
SUNWpkgcmds all are selected, because
SUNWupdatemgru depends on
SUNWswmt, and it in turn depends on
SUNWupdatemgru is in the same install metacluster as
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
/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.
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.
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.
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.
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.
Here are some additional resources: