Big shops from time to time have a demand to prepare multiple OS installation in very short amount of time. Or maybe you want to offer ‘a cloud’ with IBM i to your clients. We all know that scratch OS installation with patching the system afterwards may take several hours.
I want to describe a concept of cloning IBM i OS. Unfortunately it requires an external storage. (I’m not sure if the same functionality could not be achieved with an internal storage and Shared Storage Pools – waiting for your feedback).
It brings multiple benefits for a system administrator
- save time with OS installation and patching
- can be used as one of migration methods between remote locations
- can be used for QA/UAT test of a production environment ( you just clone the production)
What do you need to run it?
- an external storage which talks directly to IBM i
- Entire OS must be located in a storage array (boot from SAN)
- V5R3M5 – is the minimum OS ver which supports boot from SAN
How does it really work?
- A storage administrator initiate a special command,which copies all bytes of a source LUN to a target LUN.
- SAN administrator must create a new SAN zone and attach the new LUN to another IBM i LPAR
- An IBM i administrator must perform an IPL, and clean up all obsolete resources
Below you can find a command for a DS 8k which initiates a point-in-time copy from a source volume to a target volume.
Shutdown your LPAR, initiate mkflash command, use lsflash command to check if process completed.
mkflash -dev IBM.SNxxx -cp 0100:0200
lsflash -dev IBM.SNxxx -l 0200
You can do cloning between two storage arrays, then instead of flashcopy command use the mkpprc command. But you must have relevant licenses, and the arrays must talk in the same replication protocol.
Remember that cloned OS is exact copy of the source image. Therefore, all configuration remains as on your source system. I would recommend to keep a single LUN connected to a LPAR profile, and start it only for PTF patching. Consider it as a ‘gloden image’. For most of the time keep this LPAR down, to avoid waste of hardware resources.