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@opensolaris.org

Reply via email to