Jerry, 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 > > --- > > SUMMARY: > > 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. > > DETAILS: > > "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 > pkgs. 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 @ sun.com OS Ambassador Sr. Technical Specialist Solaris 10 Zones FAQ: http://www.opensolaris.org/os/community/zones/faq --------------------------------------------------------------------------
