If you need to move the entire contents of a file system, and the underlying storage doesn't need to change, you might as well just change the mount point. When you change the mount point of a file system, you effectively move all the files and directories that sail in it. Wouldn't it be wonderful if you could relocate your house and family just by slapping on a new sign on the gates of your city. In effect, that's what happens when you change the mount point.
When you want to use a new mount point - effectively rename a file system's - it doesn't take effect until you unmount the old one. And you can't do that if the file system is in use. And if a file system has nested file systems within it, then they have to come down first.
So here's the procedure. This is taken from my article Moving Mounts in the .
For more information about changing file systems, see the rest of the article.
I recommend subscribing to theIBM Systems Magazine, Power Systems edition (AIX and IBM i). It has a wealth of news and information about AIX in very accessible format. It includes a weekly blog post - AIXChange - from the indefatigable Rob McNelly. Always a great read.
AIX Down Under
Matching: mount_point X
AnthonyEnglish 270000RKFN Tags:  mount_point logical_volume mksysb lv chfs importvg chlv volume_group rootvg gentleman exclude.rootvg exportvg tsm aix manners file_system 19,731 Views
Diamond in the SAN
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
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,
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 hd4 changed 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 / already exists in /etc/filesystems.The logical volume for the file system I needed had been renamed from hd4 to fslv02, but the mount point was still set to /, so I had to change that for the newly named logical volume:
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.