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 
root-environment? 

(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 
attach-upgrading?

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 -----
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: Jerry Jelinek <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>; zones-discuss@opensolaris.org 
<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
done

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
done

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

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

_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to