This is very valuable because it would remove the most significant obstacle to "software delivery via zones."

A couple of questions inline.

Jerry Jelinek wrote:
Enclosed is a draft of an ARC fast-track proposal I have been working on
recently, in-between a few other things.  I would like to submit this for
ARC review shortly but I wanted to send this out to see if anybody had any
comments before I do that.  I have cc-ed the install-discuss alias as well,
since there is some overlap, although this is probably most interesting to
zones folks.

One additional comment.  I believe this proposal should also address the
recurring question about being able to migrate a zone from sun4u to sun4v
(and back).

Please send me any comments or questions.

Thanks, Jerry



This fast-track enhances the Solaris Zones [1] subsystem to address an existing RFE [2] requesting the ability to update a non-global zone when migrating from one machine to another.

Currently when we migrate a zone we validate that the destination host has the same pkg versions and patches for the zone-dependent packages as were installed on the source host. This is described in the zone migration ARC case [3]. While this is safe and ensures that the new host is capable of properly supporting the zone, it is also very restrictive. With this enhancement, if the new host has higher versions of the zone-dependent pkgs,

This is probably out of scope for this project, but "software delivery via zones" creates a potential security risk: software delivered via this method could have a limitpriv setting which is inappropriate in certain environments.

"Zone migration best practices" should include "after 'zoneadm -z ... attach', review the limitpriv setting with 'zonecfg -z ... info'". Should we also warn the user who just attached a zone that has a non-default limitpriv setting?

A different approach would be a mechanism to inspect the SUNWdetached.xml file and list its zonecfg-related contents *before* performing the attach. This would satisfy those organizations which are concerned by the possible omission of the "review zone's limitpriv" step.

Should either of those be include in a separate CR?

or higher versions of patches for those pkgs, then when we attach the
zone to the new host we will enable an update of the pkgs in the zone to match the new host.

Patch binding is requested for this "update on attach" capability. The stability of these interfaces is documented in the interface table below.


"Update on attach" is different from a traditional zone upgrade. In the traditional upgrade all native zones are upgraded as part of upgrading the base system using a standard Solaris media image as the source for the pkgs to upgrade to. Pkg operations on pkgs with the SUNW_ALLZONES attribute set must be run from the global zone, the operation will be performed on all native zones, and this behavior is built-in to the pkg commands.

With "update on attach" we are only updating a single zone. We cannot depend on the basic pkg behavior which updates all zones when a pkg is installed in the global zone. We cannot use standard Solaris media since the host can have a variety of patches installed which have updated the base system pkgs beyond any specific Solaris release.

Instead what we want to do is similar to what happens when a zone is initially installed. The spooled pkg data and global zone files are the source for installing the zone. In this way the zone is installed with the
correct pkg versions along with any patches that have been applied to those

Just looking for a clarification: if the intent is for the resultant zone to have the same set of pkgs as a newly created zone, will this method add any pkgs which:
1) do not exist in the detached zone
2) would be in newly created zones

We can do something similar for "update on attach". The zone 'attach' validation already generates a list of mismatched pkg versions and patches.
 We can use this information to determine which dependent pkgs need to be
updated so that the zone can run properly on the new host.  We will remove
the obsolete versions of those pkgs and install the up-to-date version from
the pkg data spooled in the global zone.  This procedure will preserve any
editable or volatile files that are delivered by these pkgs. The normal pkg
install scripts and class action scripts are run as part of this process so
any updates performed by these scripts will take place.  As described in
[3] the dependent pkgs are those that have the SUNW_PKG_ALLZONES=true pkg
attribute as well as any pkgs installed in an inherited-pkg-dir.  Only
these pkgs will be updated to match the new host.

Jeff VICTOR              Sun Microsystems            jeff.victor @
OS Ambassador            Sr. Technical Specialist
Solaris 10 Zones FAQ:
zones-discuss mailing list

Reply via email to