(CC bobn because we were talking about this last week. Start of thread at
http://mail.opensolaris.org/pipermail/zones-discuss/2008-November/004401.html)

On Wed, Nov 5, 2008 at 5:47 PM, Jerry Jelinek <[EMAIL PROTECTED]> wrote:
> If this seems like something people are interested in, I'd like to
> hear more comments and we could refine a proposal. I'll then file
> an RFE and work up an ARC proposal.

In my use cases I am aware of very few, if any, cases where I would
prefer the current implementation over an implementation that updates
all packages (not installed with -G) in the attached zone.  The
current implementation would be ideal if I installed applications (via
pkgadd) in the global zone and local zones and needed them to be
administered separately.  While I view that as a bad design, I should
be able to make it manageable via pkgadd -G.

Without an implementation that is closer to what upgrade does, I need
to patch the zone after I attach it.  If I don't patch it, I think I
will not see patches that meet the following criteria:

1. Patch is for a package that is installed in the global zone.
2. Patch is installed in global zone.
3. Package installed in non-global zone
4. Not SUNW_PKG_ALL_ZONES=true
4. Package is not fully inherited

I think, but am not sure, that my update on attach strategy will look
like:

1. Snapshot source zonepath and all other zone file systems that are
   directly attached to source server.  (Assumption is that volatile
   application data does not reside in zonepath.)
2. Send snapshot of zonepath and other file systems to destination
   server.
3. Update on attach zone.  Plan for this to take 30 - 40 minutes on
   a Niagara box.
4. Disable all networks in the zone configuration on destination
   server.
5. Single user boot, then apply the same patch set(s) that was/were
   applied to the global zone.  Plan 5 - 60 minutes.
6. Shut down zone on source server.
7. Resync (rsync or zfs send -i) each non-zonepath file system from
   source to destination.
8. Enable networks in zone configuration on destination server.
9. Boot zone on destination server.

This is a modification of my existing approach of "migrating" a zone
from one machine to another via recreating zones and synchronizing
application data.  It allows the relatively slow upgrade on attach and
patch installation processes to proceed (estimate 1 non-parallizable
hour per zone) with only a few minutes of outage to the application.
Step 5 requires steps 4 and 8 because I am not aware of a way that I
can boot a zone into "single user no network" mode.  This adds
complexity and possibly time to the update on attach process.

-- 
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to