In my original email I stated 'unless you're using flashcopy, not everyone can' EMC DASD though it can do flashcopy it cannot thru VM unless they finally added that function.
the advantage I see with Kickstart is the ability to fully config the server IP, Hostname etc, plus addition of other packages beyond a default build the ability to apply customizations via script, before the server is ever brought onto the network. again, not saying cloning is better or worse, not saying Kickstarting is better or worse saying both have advantages over cloning. cloning is cool and can be very fast. I'm equally a VM and Linux person, I like taking advantage of platform features we came up with PHP scripts and a MySQL DB to manage servers point Kickstart to the php script with passed parms. look it up in the DB to pull the network info, packages to add, custom scripts and configs worked great. William 'Doug' Carroll Mainframe Systems Eng Sr I Global Technology Infrastructure ECS Core Services z/Software Group / Emerging Technologies -----Original Message----- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of RPN01 Sent: Wednesday, June 17, 2009 2:24 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: To kick or to clone ... that is the question 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 This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. ---------------------------------------------------------------------- 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
