Point taken .. the 'real' question is how to make these things share as much as possible (code as well as hardware). Spawning penguins is only the first step towards that end..
Scott p.s. Thanks to everyone who responded to this thread - I learned alot and hope others did too. On Mon, Jun 15, 2009 at 10:00 PM, Rick Troth <r...@casita.net> wrote: > On Tue, 9 Jun 2009, Scott Rohling wrote: > > This is a blatant request for discussion about the pros and cons > > of using an automated installation (e.g. RH kickstart - Suse autoyast > > (though maybe this has changed - I'm not current on Suse) - > > vs cloning a system from a 'golden image'... > > and I should say: on zSeries. > > > Heh ... well ... you got some response to your blatant request. > GMail tells me there have been 65 messages in the thread so far, > not counting those replies which fell out of its threading model. > That's a record in recent memory. > > > Regarding the cloning -vs- kickstart/autoyast question: > It's not so much about which of those two methods one should use. > If we're serious about virtualization, then we should go deeper > than mere copying or re-deployment of content. > > > Virtualization of systems is about sharing of resources. > So think hard about sharing disks and not just memory and CPU. > On this point, cloning has a little edge. But both cloning and > jumpstarting (as usually implemented) suffer from difficulty > ferreting out the shared and sharable stuff from the per-system stuff. > But it can be done. Put the sharable stuff onto shared disks. > > > Got maint? > Apply your maint to the R/W copy, stamp out a new shared disk > from that copy, point the "client" systems to it, instant upgrade > of 500 servers without running 500 instances of RPM (or whatever). > > > There is always some per-system content > which must be either copied (clone) or deployed (kick). > The personalization of that per-system part is where jumpstart > has a little edge. Ideally, the personality would be retained > even if the rest of the op sys were blown away (er, uh, upgraded). > This is a little harder to do than sharing the op sys, but it can > be done. Start with the easy stuff, like user home directories. > > > The per-system stuff MIGHT be affected by maintenance. > If so, it complicates the sharing scheme. But it can be done. > > > So if all you ask is, "should we kick or clone?", > you're missing out substantially on the value of virtualization. > Kick or clone? Neither! Virtualize! And share! > > > -- R; <>< > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
