On 6/4/07, Wee Yeh Tan <[EMAIL PROTECTED]> wrote:
On 6/5/07, Mike Gerdts <[EMAIL PROTECTED]> wrote:
> With hundreds of zones in production today, it is feeling like later
> is already here. Worst case patching is well over 24 hours in single
> user mode. (I have developed my own workarounds to make each zone
> only add about 10 minutes to total outage time in my initial tests.)
I'll be grateful if you can share that. Patching zones is extremely
painful due to the downtime you mentioned.
The 10 minute estimate is based upon a server (V440, 36 GB disks I
think) going from 118833-36 (February-ish) to 125100-06 (May) using
the patches found in the recommended+security clusters along with a
bunch of other patches that come along for various reasons.
In a nutshell it involves ditching install_cluster from the
recommended patch bundles and using patchadd -M `pwd` `cat
patch_order`. This avoids bringing each zone up then back down for
each patch. Additionally, it calculates dependencies once.
In something much larger than a nutshell...
It is not clear to me whether it is safe to do a one-shot patching
with patchadd with current patch bundles due to the "you must reboot
now, really" code added to 118833-36. For safety sake, I have split
out 118833-36 and its prerequisites into a separate patch cluster. If
patchadd is broken after installing the first patch bundle (due to
lofs mount over pdo), it forces a reboot so that you can then install
the rest of the patches later.
Some would say that Sun Update Connection is my savior to all my
patching woes. Unfortunately, if a patch is tagged as "special
instructions apply" (or something like that) I still have to do a
bunch of futzing around between my multiple reboots. Multiple reboots
are bad enough. Futzing (hmm... futzing is a real word according the
the firefox spell checker) around between them is overly burdensome.
SUC needs to become live-upgrade aware to alleviate these problems.
One thing to keep in mind is that as zones are patched, you may pay a
per-zone copy (to /var/tmp in global zone) penalty if the patches are
sitting on NFS. I don't think this exists otherwise, but I am not
sure. I think that this is done because the patch needs to be lofs
mounted into the zone while patching, but this will break if the
source of the lofs mount is an NFS mounted directory in the global
zone. For this reason, it seems to be advisable to have the patches
on a local disk during patching. Some would argue that this is a best
practice in any case. If local disk space concerns make the use of
NFS a requirement, it may be worthwhile to explore "mount -F tmpfs -
/var/tmp" prior to beginning patching.
zones-discuss mailing list