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.


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.




    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.


"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

    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:

                -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
                -R                      same as public pkgrm option

                -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
                -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


        zoneadm attach option
                [-u]                    Evolving


        pkgremove, pkginstall and
        their options described in
        this case                       Contracted Consolidation Private


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 mailing list

Reply via email to