> I am talking about *two* LPARs: one is up and running, and I want a second > test system in a separate LPAR. > Making updates and test on the test system - copying over to the > production system. Similar to the > method we also use for z/os ... > > > You can share DASD between Linux instances, as long as the disk is read- > only to all Linux images that can see it. > Well that does not sound good.
Since you are in LPARs, you have limited options. You can create two LPARs and use IPLable DDR (or ADRDSSU for z/OS or similar standalone utilities) to make image copies from disk to disk. Given Linux's heavy use of in-memory caching, to get a clean copy using disk-to-disk copies, you *must* shut down the source to ensure the copy on disk is actually what is being used. If you try to do the copies with the test system up (ie use an active z/OS system in another LPAR to do the copies, you will not get usable data. > > You can clone a Linux image, mount the filesystem and make a few changes > to create a new image. The trick is > > knowing what to change for your Linux distribution. At a minimum, the IP > address and host name should be changed. > If you're using zVM, then all > the disk addresses and such can be the same for each system you set up. You *can* address this with system management discipline, though. You could take a snapshot of the test system with 'tripwire', do the updates, and generate a RPM of the change, or create a source RPM and build/install from source both on test and production. You could then FTP the RPM over to production and apply it with 'rpm -i' (which would give you also an easy way to keep track of what change levels are applied). There are some drawbacks if there are more than one group that needs to apply stuff at a time, but if you have a well-controlled QA process, this might do what you want. > No we don't (have) VM. And I am more than unsure (being not experienced > with Linux) how to create such a test > system. Nobody around with LPARs/without VM? Very few, and getting fewer as people realize how much LPAR management of Linux actually costs in time and aggravation. Getting VM should be a high priority for you. The manageability improvements pretty much erase the cost of VM. Wrt to creating the system: 1) define the new LPAR and assign a separate set of disks and OSA adapters to it AT THE SAME ADDRESSES as in the old LPAR (eg remap device addresses in the LPAR definition so Linux sees the same device addresses in both LPARs, but they are mapped to different real volumes and/or network devices). 2) Modify the existing LPAR to make the new set of disks available to it. 3) Shut down the existing LPAR (this is *critical*) 4) IPL standalone ADRDSSU or equivalent and copy original set of disks to new set of disks. If you have snapshot capabilities in your disk units, use that -- it's much faster. 5) remove the new set of disks from the old LPAR. 6) bring up the old LPAR 7) unplug or disable/offline the network adapter from the new LPAR. 8) bring up the new LPAR 9) from the console, use sed to update the network adapter information (or prepare a RPM or new files to do so on the old system and apply it/copy it into place on the new LPAR. 10) shut down new system 11) plug in or enable network adapter 12) bring up new LPAR. At that point you have an exact copy of the production system in your test LPAR at a different IP address. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
