I recently cloned an LPAR from a P6 to a less-busy P5 server via a mksysb backup. Unfortunately, after starting up the new LPAR I found that there was an essential directory missing because it had been excluded via the /etc/exclude.rootvg file (-e option on mksysb). Let's call the directory /diamond (its name has been changed to protect the guilty who didn't back it up).
I considered my options but each of them had a drawback.
Option 1: restore directory contents from TSM
Obstacle: unfortunately, the directory had been excluded from the TSM backup.
Option 2: shut down the new LPAR, bring up the old LPAR on the original SAN LUN and redo the mksysb
Drawback: time consuming
Option 3: bring up the old LPAR in single user mode
Drawback: I wouldn't have had a network connection to copy the files across to the new LPAR
Option 4: map the old SAN LUN to the new LPAR and import the old rootvg as a different volume group
Drawback: overwrites LV names on old rootvg LUN.
I went with option 4, which allowed me to dig out the treasured directory's contents from the SAN. It did have the drawback that it would rename logical volumes on the original SAN LUN. I was willing to take the risk. It wasn't likely I would need to boot off that LUN again. Even if I did have to, I could always rename them via SMS in single user mode before mounting file systems.
I had to get the old rootvg onto a live AIX LPAR. Here's how I did it.
An import-ant command
After mapping the old SAN LUN to the new AIX LPAR, I used importvg to import the old LPAR's rootvg under another name - oldrootvg
newhost:/ # importvg -y oldrootvg hdisk3I got some warnings which I had to deal with before getting access to the contents of the directory I needed. The first was to do with LV names, the second was mount points. Here are the details,
0516-530 synclvodm: Logical volume name hd5 changed to bootlv00.
0516-530 synclvodm: Logical volume name hd6 changed to pagelv00.
ln: 0653-421 /dev/ipl_blv exists.
Specify -f to remove /dev/ipl_blv before linking.
0516-530 synclvodm: Logical volume name hd8 changed to loglv02.
0516-712 synclvodm: The chlv succeeded, however chfs must now be
run on every filesystem which references the old log name hd8.
LVM's good manners
When you're importing a rootvg (under a different name) onto a running LPAR with its own active rootvg, there are bound to be duplicate file systems and logical volumes. Fortunately, the AIX Logical Volume Manager (LVM) shows a bit of respect - the active LPAR's file systems and LVs don't get overwritten. The new guest LUN isn't allowed to push in. Instead, if there any conflicts, the imported VG gets new LV names. So when I ran importvg, hd4 was renamed to fslv02:
0516-530 synclvodm: Logical volume name hd2 changed to fslv03.
0516-530 synclvodm: Logical volume name hd9var changed to fslv04.
0516-530 synclvodm: Logical volume name hd3 changed to fslv05.
0516-530 synclvodm: Logical volume name hd1 changed to fslv06.
0516-530 synclvodm: Logical volume name hd10opt changed to fslv07.
Here's where the LVM showed itself to be a perfect gentleman. Good guests don't push people out of their own homes.
As for file systems, I got a warning about duplicate mount points that needed to be fixed before mounting the old rootvg's file systems:
imfs: Warning: mount point /usr already exists in /etc/filesystems.
imfs: Warning: mount point /var already exists in /etc/filesystems.
imfs: Warning: mount point /tmp already exists in /etc/filesystems.
imfs: Warning: mount point /home already exists in /etc/filesystems.
imfs: Warning: mount point /opt already exists in /etc/filesystems.
chlv -L'/mnt/oldroot' fslv02At this point I created a new jfs2 log in smit lv (type jfs2log). I then set the jfs2log for my "new" root file system:
chfs -a log=/dev/loglv02 /mnt/oldroot
Finding that mount
The mount point /mnt/oldroot didn't exist, so I created the directory.
mkdir -p /mnt/oldrootI could then mount the file system /mnt/oldroot, and recover the contents of /mnt/oldroot/diamond.
I then cleaned up the oldrootvg using umount, varyoffvg and exportvg and rmdev of the disk. I then unmapped the SAN LUN which was no longer needed on the new host and was able to start the database.
I fixed the /etc/exclude.rootvg (and the TSM inclexcl file, just to be safe) and gave a quiet thanks that when importing the rootvg into an existing running LPAR, the LVM had acted as a perfect gentleman.