IBMi – Copy the load-source disk FAQ
April 15, 2019
Posted by on
Process for copying the load source disk is sort of a black box. The copying process is straight forward, but there is no documentation ‘what if’. My assumption is because this is very sensitive operation, IBM does not want us to meddle with the process. I’ve created sort of summary for admins based on my experience ,and research made over hundreds copying processes. I bet you won’t get this information thru any official channel.
First of all, before you start playing with the load-source disk, verify if you have a backup. If anything happens to the load source disk, the entire LPAR dies. You can still restore the load source, but the process is very sensitive, if something would be done incorrectly, you may end up in restoring the entire operating system.
Information in this post is the knowledge based on my research and experience. You can’t use it for arguing with IBM 🙂 IBM support very often says that some operation is not supported, not because it won’t work, but very often the result might be unpredictable.
- What copy load-source process is about? In very simple words, the process copy a crucial part of the OS data (Licensed Internal Code) from one disk/LUN to another.The disk contains all necessary information to boot the LPAR.
- When this process is necessary? Basically always, when we want to migrate from one array to another, or from one disk to another.
- Does it require an outage? Unfortunately, yes. Moreover, this process requires manual IPL, and no other operation is allowed during the operation. For instance, if for any reason, copying the load-source disk takes 3 hours, the production needs at least 3 hrs outage. Because the operation must be performed from DST, thus it has to be performed from the console. Basically the load-source disk is the only one volume which can’t be removed from the system online (since V7R1) (OMG – I hate this limitation).
- Can I cancel the copying process? (update from IBM Labs) “No, the copy is independent of the screen display, so it should keep running even if there is no console.” From my experience, it happened with V7R2, when I lost the console (LAN connection dropped), the copy process has not finished, and the system IPLed from the old Load Source. The new target load-source disk remains un-configured.
- Can I calculate time needed for copying the load-source? I afraid no, I noticed that this process takes much more time than any other disk operation. I haven’t found any logic which helps to predict time needed for copying. Of course, you can minimize number of data stored on the load-source by following commands: STRASPBAL TYPE(*ENDALC) UNIT(1), STRASPBAL TYPE(*MOVDTA). If you execute them a way in advance, the load-source would store only necessary information and all the rest will be moved to remaining disks.
- Which disk from my list is the load-source one? It is always a Unit 1, if you run an internal storage and the load-source is mirrored. Only one from these two is an active one. In order to see which one, I recommend go to SST (STRSST) and then 1 -Start a service tool, 7- Hardware Service Manager, 2-Logical hardware resources (buses, IOPs, controllers,…), 1 – System bus resources, and find IOP marked with *
Select the IOP and take option 9-Resources associated with IOP .
- Can I use copying the load-source for cloning the OS? Yes, you can. Actually, there are better ways of cloning the OS, but you can also achieve this by copying the load-source. The first requirement is condition to have the entire OS on just one disk. From performance perspective it is absolutely crazy and not recommended, but we are talking about a scenario how to copy/clone a template LPAR to many, in order to save time related to scratch OS installation and getting the PTFs. The template partition is an image which will be always just copied/cloned. The minimum size for Load-source is 35 Gb LUN on DS8k or 70Gb on internal SAS attached volume. From my experience, LUN about 40Gb is big enough to keep the entire OS with PTFs, which can be quickly, easy copied.
- How clone the OS with copying the load-source process? Get the entire OS on a single LUN, perform manual IPL, and in DST menu ,4-Work with disk units, 2-Work with disk unit recovery, 9-Copy disk unit data, select Unit 1, hit Enter and take the target disk where you want to copy data to. The copying process will take some time, and results in IPL from the new load-source. Very important!! – Power off the LPAR now and remove the new load-source from the disk configuration. If it is a physical disk then remove it from a tower, if it is a vSCSI then un-mapped from the LPAR, if it is NPIV remove it from the host configuration.After the first manual IPL from the new load-source, the system move the original load-source to non-configured units. Do not perform IPL from DST on-wards, If full IPL be performed, the original (old) load-source disk gets a boot sector information destroyed, and it will not be possible to boot the OS from it (Procedure how to revert the boot information you can find in my another post here).
- If I copy set of disks which one will be the load-source? In IBMi we can’t select the booting device, however if one of these disks contains the load-source data, the OS will find it. If load-source data is on multiple disks, only one of them remain the load-source. The remaining disks will become invalid, and the boot information gets lost.