Hi, some good point (sorry, wrong button :) )
but we do cloning only.
We use SLES10 SP2 for the moment.
It's take some time to get the disksizes right, yes, but that's the
only hook as I see it.
We have the clonebase shutdown all the time when not updating it,
and it is handled only by one or two persons, so it is clean.
For the IP-config, we have set the PFkeys in VM-profile to all
ip-config values (ip=x.x.x.x type) and read them at boot via
boot.local, and set the ip config before starting the network.
Works great, we can move servers to any subnet/zone just by update
these values and restart the vmuser (Linux reboot will not do).
We have made several scripts for the cloning and it is now a web-based
application that also checks that the clonebase is not logged on and
some more things, accountcode for example.
We use snapshot, so it takes less than two minutes before you can
login to the new server via ssh.
We also have installed WAS on a separate disk, WAS7 can have config
on another path, so that install-disk has been snapshotted to a vmuser
that only owns these disks, and they are shared readonly.
This means just one WAS7 disk and installation, and just a small config
job in each new server. Saves a lot of time and works great.
So we go for cloning.
You could snapshot the disks for a server to a vmuser just owning them
that will make it impossible to have the clonebase online when cloning.
Cordialement / Vriendelijke Groeten / Best Regards / Med Vänliga Hälsningar
Tore Agblad
Volvo Information Technology
Infrastructure Mainframe Design & Development
SE-405 08, Gothenburg Sweden
http://www.volvo.com/volvoit/global/en-gb/
________________________________________
From: Linux on 390 Port [linux-...@vm.marist.edu] On Behalf Of Scott Rohling
[scott.rohl...@gmail.com]
Sent: Wednesday, June 10, 2009 06:00
To: LINUX-390@VM.MARIST.EDU
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
