Tux on VM

Last updated on:
Sunday, July 06, 2008







Valid HTML 4.01!
Linux for Big Iron
This information was originally posted to the Linux-390 mailing list on November 29, 2001 by Mark Post, in response to the following questions by Sandy Gelbard:
Hello All,
I presently have Linux running in an LPAR.
I have 2 questions:
1) I need to move my linux vols to a different device range. I'm presently
   using RVA dasd. Is there a product that will allow me to move my disk
   packs to from my MVS system running in a different LPAR? FDRSOS does
   not apparently work with RVA. Any other practical data moving
2) The new dasd range is not currently gen'd to the linux lpar or defined
   to linux itself.  Can I just update my parmfile to include the new
   devices and then "ipl" off the new addresses once the data is moved or
   are there other procedures required?

There's an open source tool on Malcolm Beattie's web site that can do this. It can dump and restore DASD devices that are offline to OS/390. You can find it at http://www.clueful.co.uk/mbeattie/s390/offlindr.jcl.

With careful planning, you'll be able to do what you want.
  1. Make sure you understand exactly which device numbers are going to be replaced with what new device numbers.
  2. Just before you take your system down to do your backups, update your parmfile with the new device numbers _in the same relative order_ as the current ones.
  3. Re-run silo/zilo/zipl/whatever.
  4. shutdown -h now
  5. Backup and restore your DASD
  6. Re-IPL
What I mean by #2 is this...
If you currently have three DASD volumes, say device numbers 105, 102, and 313, and in that order. Then currently, you have this:
105 = /dev/dasda
102 = /dev/dasdb
313 = /dev/dasdc
If you are going to be moving those volumes to device numbers 1F33, 1E18, and 1D00, respectively, then update your parmfile to read "dasd=1f33,1e18,1d00".

Note that none of this is the way _I_ would do it if I had a choice. I would prefer to add the new DASD units to the image, and use native Linux tools to move the data. In this case that would require a longer outage (or one more outage), so that might be a consideration.


Site hosting courtesy of Velocity Software