Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

AIX LVM mirror

Status
Not open for further replies.

tamp

Vendor
Aug 12, 2002
5
HK
1. For AIX LVM - Can I mirror an existing volume in a way that the original volume comprises a bigger LUN but the added target volume with a same or larger volume size comprises several smaller LUNS? Say the existing volume was built from one 100GB physical disk, but mirroring with ten 10GB disks.

2. Is there any special consideration to migrate AIX rootvg to another physical volume(disk)? And How can I migrate the rootvg to a smaller disk?


Thanks.
 

1. Yes you can. The LVM mirrors transparently onto another VG regardless of the disks in it.

2. a. extendvg rootvg hdisk#new
b. migratepv hdisk#old hdisk#new
c. reducevg rootvg hdisk#old

Hope it works. Of course it won't work if there are more data than the smaller disk can hold. Henrik Morsing
IBM Certified 4.3 Systems Administration
 
Thanks for your advice.

Please clarify the following statement if I interpret correctly.
Regarding to q1. Provided the target volume has the same or bigger size, I can mirror the volume with the source. This option seems allow me to migrate the volume from exist PV to new disk(s).

Regarding to q2. Because the target volume is smaller than the source, I have to use your suggested method instead of volume mirroring.

Now I have two questions rasied according to your q2 approach
Q1. Data stored on the original PP would be copied to the new PP automatically after reducevg is executed. Is it right?
Q2. How does AIX handle if the machine crashed or the command set fails in the middle of the migration? How can fallback to original state except restore from bootable tape?

Thanks again.
 
Migrating a physical volume to a smaller physical volume can be done, but it is at risk of losing data; however, if all LPs on the larger pv were not used it would not be as much as a concern. But, do run an fsck after migrating to a smaller pv and also i would sync the logical volumes after doing the migration.
 
Regarding the issue of moving rootvg to another disk:

"reducevg" doesn't handle copying - that's what the "migratepv" step does.

The procedure for moving your rootvg onto another disk has a few more steps than described, but at all stages, it is possible to recover from a crash without restoring a mksysb.

1) Add new disk to rootvg "extendvg rootvg hdiskX". If there's a problem, a "synclvodm rootvg" will make sure the odm entries for rootvg are as they should be.

2) Move data. "migratepv hdisk0 hdiskX". There are a couple of things to consider crash-wise here. If the machine goes down *during* this migration, you will still have all your data from rootvg. The migratepv command mirrors data first, then deletes the copy. I forget if it mirrors everything first, then deletes everything at once, or if it mirrors 1 LV, deletes it, moves on to the next. Either way, your rootvg will still exist, it just may be spread out. You may need to clean up an incomplete mirror (not difficult), then just restart the process.

Now, if the machine crashes after you move the data, but before you do the next couple of steps, you can still do the next two steps in places other than the running OS:

3) "bootlist -o -m normal hdiskX". You can also do this in maintenance mode, or from firmware menus.

4) "bosboot -ad hdiskX" - makes the new hdisk bootable. You can also do this in maintenance mode.

Now it's all just cleanup.

5) "reducevg rootvg hdisk0" (same as step 1: synclvodm rootvg if you crash)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top