A customer asks you to migrate a WPAR from one GE (Global Environment) to another. Workload partition manager is not available so it is not possible to show off the zero downtime mobility features, but the customer does not mind a migration using backup and restore.
After requesting a shut-down of the applications, you create a WPAR backup:
savewpar -f /backup/my_wpar.backup my_wpar.
It works just fine. You know that
/etc/wpars/my_wpar.cf contains the information you would need to manually create the WPAR if problems are encountered. Confidence levels are high!
You then initiate the restore by running
restwpar -f/mnt/my_wpar.backup -n my_wpar -d /wpars/my_wpar on the destination GE, but disaster strikes!
# restwpar -f/mnt/my_wpar.backup -n my_wpar -d /wpars/my_wpar
New volume on /mnt/my_wpar.backup:
Cluster size is 51200 bytes (100 blocks).
The volume number is 1.
The backup date is: Fri Jan 10 11:26:56 SAST 2014
Files are backed up by name.
The user is root.
x 4739 ./.savewpar_dir/wpar.spec
x 20557 ./.savewpar_dir/image.data
x 187511 ./.savewpar_dir/backup.data
The total size is 212807 bytes.
The number of restored files is 3.
mkwpar: Creating file systems...
Creating logical volume 'fslv16' specified in image.data
0516-082 lqueryvg: Unable to access a special device file.
Execute redefinevg and synclvodm to build correct environment.
bosinst_chklvattrs: error running lqueryvg
bosinst_mklvflags: unknown value 0 for attribute MIRROR_WRITE_CONSISTENCY in LV fslv16
bosinst_mkobject: could not make flag for attribute MIRROR_WRITE_CONSISTENCY
0516-1242 mklv: The -s parameter for Strict must be y, n or s.
bosinst_mkobject: failed command: /usr/sbin/mklv -P 660 -G 0 -U 0 -o n -L / -u 1024 -r y -b y -d p -v n -s 4 -a m -e m -c 1 -x 512 -t jfs2 -y fslv16 erp-datavg 4 hdisk17
wparidata: Error processing image.data
umount: 0506-347 Cannot find anything to unmount.
umount: 0506-364 There are no file systems of type my_wpar currently mounted.
restwpar: 0960-514 /usr/sbin/mkwpar exited with return code 1.
You could log a call but where's the fun in that? You instead rely on your super-user detective skills and instantly narrow the defect down to the following:
Reading through the APAR, it is clear that a modification of image.data is required, since applying the fix and repeating the process on the source GE is not feasible. The image.data file can simply be grabbed from the source system or if it is not available, it will have to be extracted from the WPAR backup file via the following command:
restore -xvf /mnt/my_wpar.backup ./.savewpar_dir/image.data
You are now able to modify the image.data file, and change the invalid entries to address the defect.
(On my system, I actually had LUNS mapped to another LPAR and the PV numbers for the volume group differed. So all the hdisk numbers had to be modified as well)
Now simply rerun the command using the modified file:
restwpar -f/mnt/my_wpar.backup -n my_wpar -d /wpars/my_wpar -i ./.save_wpar_dir/image.data
You head off to the coffee machine whilst soaking up stares of appreciation. It's going to be a fine day.