On 6/4/07, Wee Yeh Tan <weeyeh at gmail.com> wrote: > On 6/5/07, Mike Gerdts <mgerdts at gmail.com> 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. Mike -- Mike Gerdts http://mgerdts.blogspot.com/
