In a perfect world you define a standard build (Golden Image), deploy it, and then let it be, never touching it again…..right? If you can answer “yes” to this, I’d like to shake your hand. In most of the environments I’ve worked in, even the term “standard” is relative. You have a patches that are released, configs that change, and technology that gets updated or made obsolete. There are many forces that would cause your beloved golden image to be made “null and void”. That being said, you sometimes have to revisit older machines deployed in the beginning and bring them up to new standards.
In a few environments, you may even be faced with picking up the pieces where other, less skilled folk, may have been in charge. This can often leave you scratching your head asking, “What in the heck were they thinking…” One common scenario I’ve encountered is when someone built the system and included application/database volumes within “rootvg”. Although not a complete wreck, I highly recommend not doing this, for more reasons than it’s worth to explain. This leads me to the topic if this post, how to migrate a logical volume from one volume group to another. Let’s dive in:
NOTE: This example shows how to migrate the “optopenv” LV from “rootvg’ to “nbuvg” and renames the LV to “nbu_optopenv_lv”
Create new VG (or use an existing VG)
1 | $ mkvg -S -y [vgname] -s [pp size in MB] [pv1] [pv2] ... |
EXAMPLE:
1 | $ mkvg -S -y nbuvg -s 512 hdisk3 |
Copy the LV to the new VG
NOTE: The LV being copied needs to be inactive for this, please make sure the associated FS is unmounted
1 | $ cplv -v [new vg] [lv name] |
EXAMPLE:
1 | $ cplv -v nbuvg optopenv |
NOTE: The new LV will have a generic name similar to “lv00”
Setup LV log
– For inline log FS’s
1 | $ logform /dev/[lvname] |
EXAMPLE:
1 | $ logform /dev/lv00 |
– For external log
1 | $ mklv -t jfs2log [vg name] 1 |
EXAMPLE:
1 | $ mklv -t jfs2log nbuvg 1 |
NOTE: this will create a new log LV similar to “loglv00”
1 | $ logform /dev/loglv00 |
Change the FS to reference the new log
– For inline log FS’s
1 | $ chfs -a /dev/[lv name] -a log=INLINE /filesystem |
EXAMPLE:
1 | $ chfs -a /dev/lv00 -a log=INLINE /opt/openv |
– For external log FS’s
1 | $ chfs -a /dev/[lv name] -a log=/dev/[log lv name] /filesystem |
EXAMPLE:
1 | $ chfs -a /dev/lv00 -a log=/dev/loglv00 /opt/openv |
Perform a FS integrity check
1 | $ fsck -p /dev/[lv name] |
EXAMPLE:
1 | $ fsck -p /dev/lv00 |
NOTE: It is common to receive errors after running fsck -p /dev/lvname prior to mounting the filesystem.
These errors are due to a known bug that development is currently aware of and which will be resolved in a future release of AIX.
Once the filesystem is mounted, a future fsck with the filesystem unmounted should no longer produce an error.
Mount the FS
1 | $ mount /[fs name] |
EXAMPLE:
1 | $ mount /opt/openv |
Remove old LV
1 | $ rmlv [old lv name] |
EXAMPLE:
1 | $ rmlv optopenv |
Rename new LV
1 | $ chlv -n [new name] [old name] |
EXAMPLE:
1 | $ chlv -n nbu_optopenv_lv lv00 |
Very good post and beautifully laid out – very readable. Perhaps it’s worth pointing out that when you move a logical volume to a new volume group, the file system must not be in use.
If you’re migrating within a volume group (to different Physical Volumes), then you ought to be able to do it online using commands like mklvcopy and rmlvcopy, or just migratepv.
But this post is about moving out of rootvg. I agree – I’ve always found it good practice to give rootvg the space it needs and keep data file systems in other volume groups.