Planning a nimadm Migration With No Free Disk
A NIM master runs AIX 7.2 TL5 with a 7200-05 lpp_source and a matching SPOT. A business LPAR, configured as a NIM client at AIX 7.2 TL3, must move to TL5 inside a six-hour window; the application can tolerate only about 30 minutes of downtime for the final reboot. The client's rootvg is mirrored across hdisk0 and hdisk1, both 200 GB LUNs with roughly 140 GB of used space per copy. No free disks exist in rootvg, the SAN free pool is exhausted until next quarter, and datavg holds 400 GB of unrelated data. The NIM master's /export/nim filesystem has 60 GB free. The administrator proposes running nimadm against the client as-is and 'letting it sort out the target disk'. The change board wants to know whether the plan can finish in the window and how to get back if it fails.
1. Evaluate the administrator's plan. What must be true before nimadm can run against this client, and which of those conditions fail here?
Read the worked answer
nimadm is an alternate-disk migration: it takes a system backup of the running client, restores it to a separate target rootvg, applies the lpp_source through NIM, and then reboots the client onto that alternate rootvg. It requires three kinds of free space, and the plan has checked none of them.
On the client: target disks that are not members of a volume group, at least as large as the used space in rootvg plus margin. Here every disk is in rootvg or datavg, so there is no target. On the master: the client's system image is staged in the NIM cache filesystem (by default under /export/nim/cache), which must hold roughly the client's used rootvg; 60 GB free against 140 GB used fails by a wide margin. Also required: the client's NIM configuration, working rsh or ssh between master and client, bos.alt_disk_install available, and a SPOT and lpp_source that match the target level, so the master's 7.2 TL5 pair is the one part of the plan that is correct.
So the honest answer to the change board is that as written it fails on target disk and on cache space, and 'letting it sort out the disk' is not a behaviour nimadm has; it either finds a free target or aborts.
2. The window is today and no new LUN can be delivered. What is the viable path, what risks does it introduce, and what would you tell the change board?
Read the worked answer
Free the free space the client already owns. Break the mirror deliberately rather than by accident: unmirrorvg rootvg hdisk1, then reducevg rootvg hdisk1, which leaves rootvg on hdisk0 alone and makes hdisk1 an unassigned disk of 200 GB, enough for the 140 GB of used space plus margin. Set the boot list to hdisk0 only and run bosboot on hdisk0 before starting, so the fallback is explicit. Add cache space on the master or point the cache at a filesystem with 150 GB or more free, otherwise the run stops early regardless of the client.
Risks, stated plainly: the client runs without rootvg redundancy for the duration of the migration; if hdisk0 fails during the window the recovery is a mksysb restore, not a reboot. hdisk1 still holds the old mirror copy and will be overwritten, so it must not be re-imported by mistake. nimadm itself runs online, so the 30-minute application downtime is only the final reboot into the alternate rootvg, which fits comfortably inside six hours if the cache is sized correctly.
The change board answer: plan is feasible, with a temporary loss of rootvg mirroring and a rollback path that is the untouched hdisk0.
3. How do you validate success and how do you roll back if the client does not boot cleanly into the new rootvg?
Read the worked answer
Before the reboot, confirm the alternate rootvg was built and populated: alt_rootvg_op -W -d hdisk1 makes the alternate rootvg visible as altinst_rootvg, and lsvg -l altinst_rootvg should show every filesystem present. Check the boot list and the boot image on the target before rebooting rather than discovering a problem at the console.
After the reboot, validate three things in order: oslevel -s and lslpp -l confirm the TL actually applied; lspv and lsvg -p rootvg confirm the system is running from the intended disk; and the application smoke test confirms nothing was left behind. Only then remove the alternate rootvg marker on the old disk.
Rollback is the strongest part of this design: the original rootvg on hdisk0 was never modified by nimadm. If the client does not boot, point bootlist -m normal back at hdisk0 from the repair shell and reboot; you are back on TL3 with the old data intact within minutes. Record that command in the change record before the window, not after, and confirm the old rootvg still has a valid boot image before you start.