Another point is that cloning can take advantage of the IBM DASD Flashcopy, which Kickstart cannot. In our cloning process, copying the volumes with DDR takes roughly 8 seconds or so, for two 3390-27's. Kickstart can't copy the data onto the DASD that fast, so I don't see how it could be quicker in any sense.
-- Robert P. Nix Mayo Foundation .~. RO-OE-5-55 200 First Street SW /V\ 507-284-0844 Rochester, MN 55905 /( )\ ----- ^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 6/10/09 7:55 AM, "Scott Rohling" <scott.rohl...@gmail.com> wrote: > Hi Doug -- Yep, we sure had some fun kicking Linux servers! > > Not sure how Linux not doing restarting itself is an IBM issue... but that > 'is' a nasty downside to kickstarting -- ending up at a 'You may safely > reboot' screen doesn't help automation. > > And we should add that kickstarting is faster than cloning 'if' the DASD is > already Linux formatted.. if not, the kickstart does the formatting, adding > time to the install. > > Scot > > On Tue, Jun 9, 2009 at 11:39 PM, WILLIAM CARROLL <v...@smgvbest.com> wrote: > >> Hi Scott, >> >> I'll jump on your bandwagon but then again you already know I perfer >> Kickstarting over cloning >> you should also mention that unless you have Flashcopy for your DASD >> Kickstarting is actually faster than cloning. >> unless your clone master is very small. >> >> as you recall ours was on a mod3 (lots of required garbage) and cloning >> that mod3 was slower than kickstarting >> also after the kickstart was done the server was ready, no additional >> steps >> to change IP's or anything. >> >> if only redhat would fix that re-ipl after the reboot. >> they say it's an IBM issue not thiers >> >> Doug Carroll >> >> >> >> ----- Original Message ----- >> From: "Scott Rohling" <scott.rohl...@gmail.com> >> To: <LINUX-390@VM.MARIST.EDU> >> Sent: Wednesday, June 10, 2009 12:00 AM >> Subject: To kick or to clone ... that is the question >> >> >> 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. >>> >>> I'm a fan of kickstart - and I'll list my reasons in approximate order of >>> importantance to me (most to least): >>> >>> - kickstart forces a scripted and recreatable installation. You specify >>> the rpm's and can do some limited scripting within the kickstart file >>> itself >>> to end up with (hopefully) a working Linux system that requires no manual >>> tweaking (at least - if you do it 'right'). The alternative is a cloned >>> system that the Linux SA's have been on, and perhaps several other teams - >>> all performing manual tasks to end up with the final product - all sorts >>> of >>> shoeprints and no good detectives. Whereas a kickstart config is >>> self-documenting - a clone is not. With good scripting and good use of >>> rpm >>> packaging for your 'local' or even 'vendor' products - you can end up with >>> a >>> very KISS config file that might even go multiplatform. (e.g. arch=`uname >>> -m` ) >>> >>> - with a proper building of conf and parm files on z/VM - a guest can be >>> kicked already configured with a working network -- no need for some >>> outside >>> scripting or manual config. >>> >>> - you can have different kickstart files for different server 'types' >>> (web, >>> app, db, etc) - these can even be built dynamically and requested via a >>> URL >>> to to the kickstart ( e.g. >>> http://mykicker/kick.web&ip=xx.xx.xx.xx+etc+etc.....) >>> >>> - The size of the DASD can be flexible.. cloning requires copying the >>> same >>> size DASD as the source.. >>> >>> - The latest fixes can be applied by keeping the repository the kickstart >>> uses current - rather than updating a clone source. (of course - testing >>> is >>> still required and would require kickstarting a guest to truly do any >>> testing - a good thing imo) >>> >>> - It encourages packing by rpm rather than manual 'tarball' methods.. >>> this >>> is in line with a 'recreatable' install. Yes, you can still do 'tar' >>> commands in the kickstart file itself.. but specifying an rpm package is >>> oh >>> so much easier. >>> >>> - Servers start 'clean' - ie no old log files from the clone source and >>> no >>> need to try and script a 'cleanup' >>> >>> - No worrying about whether a clone source is 'up' when a new server is >>> clone and possibly clone a live system >>> >>> >>> There are downsides.. but I'll leave those to the rest of you to expound >>> on, since I'm taking a position of 'kickstart good, Jane' >>> >>> Thanks and hope this is valuable to some .. >>> >>> Scott >>> >>> ---------------------------------------------------------------------- >>> 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 >> > > ---------------------------------------------------------------------- > 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
