|The point was that the actual Linux guests certainly never need write access to their own |191 minidisk
True for cloning -- not true if you use the RedHat 'kickstart' method (or SuSE autoyast, which I haven't tried, personally). I've helped several clients implement an 'automated kickstart' - which involves creating the necessary config files on the 191 (or other addressed) disk, punching the install kernel to the reader and ipling the reader. The config file points to a kickstart config on an install server -- and the automated install takes off. A new server is created this way rather than cloning.. Don't want to open a debate on this, but there are some benefits to doing things this way instead of using a clone source and flashcopy/ddr: - Network is already configured by the config file and the kickstart - It can support any size disk(s) rather than a 3390-3/9 .. the kickstart can also contain the partitioning info to support different needs - It forces the install to a repeatable, scriptable set of steps - rather than copying something several people have been tromping on (clone source). - Forces product installs to repeatable, scriptable set of steps - use different kickstart configs rather than different clone sources. - Time is still low: 5 minutes (if DASD is pre-formatted - big if) .. Anyway -- to 'kick things off' - you need some writable space for the unique config files.. Most customers that do it I've encouraged to use TDISK - it's the safest, least complicated way to get temp space - and you don't have to worry about concurrent installs grabbing some disk. I've also seen each guest given it's own 191 - but I'm sure we'd all agree that while it's safe and uncomplicated -- it's a nightmare -- you want to maintain one common PROFILE EXEC - not hundreds. So my vote is: - Use common 191 with read only link (minidisk or SFS) - Use TDISK when writable area is necessary (like an automatic install or kickstart) Scott Rohling
