Hi Jerry,
This proposal mentions "native" zones.
Please ensure that the "cluster" brand is treated
as a "native" brand, as noted in PSARC 2007/304.
By the way PSARC 2007/304 was approved last week.
The changes are now in Nevada. We have been working
with the ON & Install gate C-teams. The changes will
go into the S10u4 gates once we receive notification of what date
they want the putback to occur. After the changes
get into both S10u4 gates, I will return to discuss the
long-term solution for S10u5.
Regards,
Ellard
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, 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.
>
> 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.
>
> We will ensure that we will only update a zone to a host running the
> same
> or later version of the dependent pkgs. For example, if the new
> host has
> a mix of higher and lower version patches as compared to the source
> host
> then we will not allow an update during the attach.
>
> By default the zone will not be updated during attach. Instead, the
> existing output listing the pkgs that are out of sync will continue to
> be printed. We will add a new option (-u) to the 'zoneadm attach'
> subcommand. When this option is used then zoneadm will update the
> necessary pkgs during the attach (assuming there are any to update).
>
> Because the zone has previously booted and run on the source host it is
> possible that there could be security issues with directly accessing
> the
> zone's filesystem to remove and add pkgs to the zone. To protect
> against
> this the pkg operations will be performed within the scratch zone
> [4]. The
> scratch zone was defined to address this specific issue for upgrading
> zones.
>
> We cannot use the pkgrm(1M) and pkgadd(1M) commands to update the zone
> while running within the scratch zone. Those commands explicitly
> disallow removing or adding a pkg with the SUNW_ALLZONES attribute set
> unless running in the global zone. Instead we will use the
> /usr/sadm/install/bin/pkgremove and /usr/sadm/install/bin/pkginstall
> commands directly. The pkgrm and pkgadd commands are wrappers to those
> commands. Those commands were formerly part of the ON consolidation
> but
> moved to the Install consolidation as part of [5]. That case
> documents man
> pages for pkgremove and pkginstall but no such man pages exist. No
> stability level is documented for these two commands so we're assuming
> these are consolidation private and a contract is needed to directly
> use
> these commands. The command line options being used are:
>
> /usr/sadm/install/bin/pkgremove:
> -a same as public pkgrm option
> -F private - used by upgrade to
> suppress
> actual removal of files
> delivered by
> the pkg
> -M same as public pkgrm option
> -n same as public pkgrm option
> -O inherited-filesystem={IPD} private - used to specify
> the zone's
> inherited-pkg-dir
> entries
> -R same as public pkgrm option
>
> /usr/sadm/install/bin/pkginstall:
> -a same as public pkgrm option
> -C private - disable checksums
> since files
> are installed via a separate
> copy from
> the global zone
> -h private - enable hollow pkg support
> -N pkgadd private - error msgs use use the
> name
> "pkgadd" instead of "pkginstall"
> -n same as public pkgrm option
> -O addzonename private - error msgs include
> zonename
> -O inherited-filesystem={IPD} private - used to specify
> the zone's
> inherited-pkg-dir
> entries
> -R same as public pkgrm option
> -S private - suppress copyright output
> -t private - suppress spooled pkg
> creation
> -z private - install zone pkg data
> from
> spooled pkg data
>
> EXPORTED INTERFACES
>
> zoneadm attach option
> [-u] Evolving
>
> IMPORTED INTERFACES
>
> pkgremove, pkginstall and
> their options described in
> this case Contracted Consolidation Private
>
> REFERENCES
>
> 1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris
> 2. RFE: zoneadm attach should patch/update the zone to the new hosts level
> Bugid 6480464 http://bugs.opensolaris.org/view_bug.do?bug_id=6480464
> 3. PSARC/2006/030 Zone migration
> 4. PSARC/2005/474 Zones Upgrade
> 5. PSARC/2002/274 Move SVr4 Packaging from ON to ADMIN
> _______________________________________________
> zones-discuss mailing list
> zones-discuss at opensolaris.org
