Migrating an LV from one VG to another

Posted by on Feb 9, 2012 in Blog, Featured, Software | 1 comment

Migrating an LV from one VG to another

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

 

Joe Searcy is a UNIX Systems Engineer living in Atlanta, GA. He’s an avid Power Systems enthusiast with a very diverse IT background. He’s a Certified IBM Systems Administrator for AIX 6.1, and is the founder of this site. In addition to promoting the Power Systems community, Joe enjoys working with Open Source software and currently contributes on a few projects.

One Comment

  1. 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.