On Thursday, July 08, 2004 10:48 AM Adam Thornton wrote: > On Thu, 2004-07-08 at 09:41, Daniel Jarboe wrote: > > the real issue was the > > effort that went into applying any updates and keeping the rpm database > > current on each guest. Stability was no problem. > > I haven't found a better way to do this than a sacrificial clone of the > pre-service basevol attached r/w to each guest before you apply the > per-disk service. After you've done that, reIPL the guest with the > shared (updated) r/o disk, and reimage the sacrificial disk with the > pre-service state, and move on to the next guest. > > Is there a better way?
We arrived at our process after quite a bit of discussion on the list... someone was doing something similar to what we ended up with. We did the rpm -Uhv's on a copy of the current production basevol (not each guest), and then ipled each guest off the basevol during that guest's window. BUT, before we applied the maintenance on the basevol, we manually checked to ensure that that upgrade did not change guestvol files. Also, we manually checked rpm -qp file.rpm --scripts to ensure nothing there would touch guestvol files. In all our RH rpm updates, I don't remember any needing special action on the guests except maybe a one-liner a single package needed to rebuild a file. This required us to run that script on each of the guests, but this too we put in the startup scripts on the basevol so the guest could do it automatically the first time it came up, based on whether a file existed on the guestvol. Nothing fancy, but it was sufficient. It still required an IPL of the guest just to update one measly binary, though, because everything was shared RO. We also shared the rpm database r/o, but that isn't necessarily a requirement. You can rpm -Uhv --justdb the maintenance on each of the guests if you want each to have its own R/W rpm db without adding a second db. Again this worked because except for rare exceptions, the maintenance never changed guestvol files. For new package installs, you'd need to get the guestvol files there, but again this could be automated in the basevol startup scripts by checking if a file existed and if not untar a tarball. ~ Daniel ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
