I like your eaxample... Good way to go if you can't swing the zones over to 
some other server for import/attach/upgrade. 

How would you envision backing out of the newbe environment if (after doing the 
zoneimport +upgrade) you decide you want to back out and boot to the pre-lu 

(You can't attach -u the luns for downgrade purposes can you? The zones would 
be seriously out of whack as a result of the attach/upgrade.)

I guess if there WAS zfs in play, at least you could snapshot before 

The whole attach+upgrade thing is a little scary anyway, some sort of backout 
will be needed... 

Maybe put the zones in some lu-state before doing the attach+upgrade? Maybe 
that's the suggested way to do this anyay? (Lu the whole shabang, which will 
give you clean backout of zones and root-env)

As mike said, we're going to have zfs play in this space sooner or later, and 
its snapshot facilities can really help solve some serious issues here.

Interesting development... Attach+upgrade zones is flirting with "killer-app" 
status, especially when combined with zfs clones/snapshots.

My 2 cents, 

  -- mikee

----- Original Message -----
To: Jerry Jelinek <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>; zones-discuss@opensolaris.org 
Sent: Mon Jun 04 19:29:00 2007
Subject: Re: [zones-discuss] updating a zone when attaching

On 6/4/07, Jerry Jelinek <[EMAIL PROTECTED]> wrote:
>      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.

This seems to imply I can do something along the lines of:

lucreate -n newbe ...

for zone in $allzones ; do
    zoneadm -z $zone halt
    zoneadm -z $zone detach

luupgrade -t -n newbe -s /tmp/10_Recommended ...
luactivate newbe
init 6

for zone in $allzones ; do
    zoneadm -z $zone attach -u
    zoneadm -z $zone boot

But S10u4 adds support for live upgrade of zones, right?  It doesn't
do it if I have ZFS in the mix.  Since there is no mention of timeline
for live upgrade on a system with zones on ZFS (significant pain
point) this looks very promising.


Mike Gerdts
zones-discuss mailing list

zones-discuss mailing list

Reply via email to