vg – A Daily Dose of Power https://ddpwr.com IBM Power Systems and the Like Tue, 27 May 2014 20:40:41 +0000 en-US hourly 1 https://wordpress.org/?v=4.9.3 Migrating an LV from one VG to another https://ddpwr.com/2012/02/migrating-an-lv-from-one-vg-to-another/ https://ddpwr.com/2012/02/migrating-an-lv-from-one-vg-to-another/#comments Thu, 09 Feb 2012 05:16:09 +0000 http://ddpwr.com/?p=123 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)

$ mkvg -S -y [vgname] -s [pp size in MB] [pv1] [pv2] ...

EXAMPLE:

$ 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

$ cplv -v [new vg] [lv name]

EXAMPLE:

$ cplv -v nbuvg optopenv

NOTE: The new LV will have a generic name similar to “lv00”

Setup LV log

– For inline log FS’s

$ logform /dev/[lvname]

EXAMPLE:

$ logform /dev/lv00

– For external log

$ mklv -t jfs2log [vg name] 1

EXAMPLE:

$ mklv -t jfs2log nbuvg 1

NOTE: this will create a new log LV similar to “loglv00”

$ logform /dev/loglv00

Change the FS to reference the new log

– For inline log FS’s

$ chfs -a /dev/[lv name] -a log=INLINE /filesystem

EXAMPLE:

$ chfs -a /dev/lv00 -a log=INLINE /opt/openv

– For external log FS’s

$ chfs -a /dev/[lv name] -a log=/dev/[log lv name] /filesystem

EXAMPLE:

$ chfs -a /dev/lv00 -a log=/dev/loglv00 /opt/openv

Perform a FS integrity check

$ fsck -p /dev/[lv name]

EXAMPLE:

$ 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

$ mount /[fs name]

EXAMPLE:

$ mount /opt/openv

Remove old LV

$ rmlv [old lv name]

EXAMPLE:

$ rmlv optopenv

Rename new LV

$ chlv -n [new name] [old name]

EXAMPLE:

$ 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.
]]>
https://ddpwr.com/2012/02/migrating-an-lv-from-one-vg-to-another/feed/ 1