dropdown menu


LVM (Logical Volume Manager):
LVM manages the storage to have a structured overview of it.

/var/adm/ras/lvmcfg.log        lvm log file shows what lvm commands were used (alog -ot lvmcfg)
alog -ot lvmt                  shows lvm commands and libs

The LVM consists of:
    -high level commands: can be used by users, e.g.: mklv (this can call an intermediate level command)
    -intermediate level commands: these are used by high-level commands, e.g. lcreatelv (users should not use these)
    -LVM subroutine interface library: it contains routines used by commands, e.g. lvm_createlv
    -Logical Volume Device Driver (LVDD): manages and processes all I/O; it is called by jfs or lvm library routines
    -Disk Device Driver: It is called by LVDD
    -Adapter Device Driver: it provides an interface to the physical disk

This shows how the execution of a high level command goes through the different layers of LVM:


After you create a volume group, you can create logical volumes within that volume group. Logical partitions and logical volumes make up the logical view. Logical partitions map to and are identical in size to the physical partitions. A physical partition is the smallest unit of allocation of disk where the data is actually stored. A logical volume is a group of one or more logical partitions that can span multiple physical volumes. All the physical volumes it spans must be in the same volume group.

A logical volume consists of a sequence of one or more logical partititons. Each logical partition has at least one and a maximum of three corresponding physical partitions that can be located on different physical volumes.

When you first define a logical volume, the characteristics of its state (LV STATE) will be closed. It will become open when, for example, a file system has been created in the logical volume and mounted.
It is also possible that you might want to create a logical volume and put nothing on it. This is known as a raw logical volume. Databases frequently use raw devices

Logical Volume types:
    - log logical volume: used by jfs/jfs2
    - dump logical volume: used by system dump, to copy selected areas of kernel data when a unexpected syszem halt occurs
    - boot logical volume: contains the initial information required to start the system
    - paging logical volume: used by the virtual memory manager to swap out pages of memory

users and appl.-s will use these lvs:
    - raw logical volumes: these will be controlled by the appl. (it will nit use jfs/jfs2)
    - journaled filesystems:

Striped logical volumes:
Striping is a technique spreading the data in a logical volume across several physical volumes in such a way that the I/O capacity of the physical volumes can be used in parallel to access the data.

LVCB (Logical Volume Control Block)
First 512 byte of each logical volume in normal VGs (In big VGs it moved partially into the VGDA, and for scalable VGs completely.)(traditionally it was the fs boot block) The LVCB stores the attributes of the LV. Jfs does not access this area.
# getlvcb -AT <lvname>                                <--shows the LVCB of the lv


LOGICAL VOLUME:     hd2                    VOLUME GROUP:   rootvg
LV IDENTIFIER:      0051f2ba00004c00000000f91d51e08b.5 PERMISSION:     read/write
VG STATE:           active/complete        LV STATE:       opened/syncd
TYPE:               jfs                    WRITE VERIFY:   off
MAX LPs:            512                    PP SIZE:        32 megabyte(s)
COPIES:             2                      SCHED POLICY:   parallel
LPs:                73                     PPs:            146
STALE PPs:          0                      BB POLICY:      relocatable
INTER-POLICY:       minimum                RELOCATABLE:    yes
INTRA-POLICY:       center                 UPPER BOUND:    32
MOUNT POINT:        /usr                   LABEL:          /usr
Serialize IO ?:     NO

inter-policy    inter-physical volume allocation policy, can be minimum or maximum
                minimum: to allocate pp's the minimum pv will be used (not spreading to all pv's tha data if possible)
                maximum: to spread the physical partitions of this logical volume over as many physical volumes as possible.

each lp copy on separate pv    The strictness value. Current state of allocation, strict, nonstrict, or superstrict. A strict allocation states that no copies for a logical partition are allocated on the same physical volume. If the allocation does not follow the strict criteria, it is called nonstrict. A nonstrict allocation states that copies of a logical partition can share the same physical volume. A superstrict allocation states that no partition from one mirror copy may reside the same disk as another mirror copy. (mirror 2 and mirror 3 cannot be on the sam edisk)

(So inter-policy and strictness have effect together how many disks are used: spreading to maximum disks (1st lps) then mirroring them we need another bunch of disks; however spreading to minimum disks and mirroring, we need less disks.)

This illustration shows 2 physical volumes. One contains partition 1 and a copy of partition 2. The other contains partition 2 with a copy of partition 1. The formula for allocation is Maximum Inter-Disk Policy (Range=maximum) with a Single Logical Volume Copy per Disk (Strict=y).

intra-policy    intra-physical volume allocation policy, it specifies what startegy should be used for choosing pp's on a pv.
                it can be: edge (outer edge), middle (outer middle), center, inner middle, inner edge

If you specify a region, but it gets full, further partitions are allocated from near as possible to far away.
The more i/o-s used, the pp's should be allocate to the outer edge.

mirror write consistency If turned on LVM keeps additional information to allow recovery of inconsistent mirrors.
                  Mirror write consistency recovery should be performed for most mirrored logical volumes
                  MWC is necessary to mirror lvs with parallel scheduling policies.

sched policy      how reads and writes are handled to mirrorred logical volumes
                  parallel (default): read from least busy disk, write to all copies concurrently (at the same time)
                  sequential: read from primary copy only (if not available then next copy). write sequential (one after another)
                  (1 book suggests sequential because it works with MWC)

Write verify      If turned on, all writes will be verified with a follow-up read. This will negatively impact performace but useful.

BB policy         Bad block relocation policy. (bad blocks are relocatable or not)

Relocatable       Indicates whether the partitions can be relocated if a reorganization of partition allocation takes place.

Upper Bound
       what is the maximum number of physical volumes a logical volume can use for allocation


# lslv -l pdwhdatlv

PV                COPIES        IN BAND       DISTRIBUTION
hdiskpower5       125:000:000   3%            000:004:000:076:045

Copies            shows information of each copies (separated by :) on the disks (125 first copy and no other mirrors are on the disk)

In Band           the percentage of pps on the disk which were allocated within the region specified by Intra-physical allocation policy

Distribution      how many pps are allocated in: outer edge, outer middle, center, inner middle, and inner edge (125=4+76+45)


lslv lvname       displays information about the logical volume
lslv -m lvname    displays the logical partitions (LP) and their corresponding physical partititons (PP)
lslv -l lvname    displays on which physical volumes is the lv resides
lslv -p <hdisk>   displays the logical volume allocation map for the disk (shows used, free, stale for each physical partition)
lslv -p <hdisk> <lv> displays the same as above, just the given lv's partitions will be showed by numbers

    Open          Indicates active if LV contains a file system   
    Closed        Indicates inactive if LV contains a file system   
    Syncd         Indicates that all copies are identical   
    Stale         Indicates that copies are not identical   

mklv -y newlv1 datavg 1    create logical volumes (mklv -y'testlv' -t'jfs' rootvg 100 <--creates jfs with 100 lp)
    -y newlv1     name of the lv
    datavg        in which vg the lv will reside
    1             how many logical partitions add to the lv

mklv -t jfs2log -y <lvname> <vgname> 1 <pvname> creates a jfs2log lv (after creation format it: logform -V jfs2 <loglvname>)

rmlv              removes a logical volume
rmlv -f loglv     removes without confirmation

mklvcopy bblv 2 hdisk2    make a 2nd copy (1LP=2PP) of bblv to hdisk2 (synchronization will be needed: syncvg -p hdisk2 hdisk3)
rmlvcopy bblv 1 hdisk3    leave 1 copy (1LP=1PP) only and remove those from hdisk3

getlvcb           display the LVCB (Logical Volume Control Block) of a logical volume
extendlv          increasing the size of a logical volume
cplv              copying a logical volume
chlv              changes the characteristic of a logical volume

migratelp testlv/1/2 hdisk5/123 migrates testlv's data from the 1st lp's second copy to hdisk5 on pp 123
                 (output of lspv -M hdiskx can be used:lvname:lpnumber:copy, this sequence is needed)
                 (if it is not mirrorred than easier this way: migratelp testlv/1 hdisk3)
                 (if it is mirrorres and we use the above commande, than 1st copy will be used: testlv/1/1...)

migratelp in for cycle:
for i in $(lslv -m p1db2lv | grep hdiskpower11 | tail -50 | cut -c 2-4); do migratelp p1db2lv/$i hdiskpower3; done

lresynclv        resync a logical volume (???maybe if mirrorred???


Creating a new log logical volume:

1. mklv -t jfs2log -y lvname vgname 1 pvname        <-- creates the log lv
2. logform -V jfs2 /dev/lvname
3. chfs -a log=/dev/lvname /fsname                  <--changes the log lv (it can be checked in /etc/filesystems)


Resynchronizing a logical volume:

1. root@aix16: / # lslv hd6 | grep IDENTIFIER
LV IDENTIFIER:      00c2a5b400004c0000000128f907d534.2

2. lresynclv -l 00c2a5b400004c0000000128f907d534.2


Striped lv extending problems:

extending is only possible by the stripe width (if it is 2, the extended lp should be 2,4,6...)
if lv can't be extended upper bound can cause this:

lslv P02ctmbackuplv | grep UPPER

It means that the lv can only be on 2 disks, but if on those 2 disks has no more space it can't be extebded to other disks.
upper bound should be changed: chlv -u 4 P02ctmbackuplv

After this extension should be possible

Unable to find lv in the define configuration database

1. synclvodm <vgname>         <-- rebuild the volume group descriptors on the physical volume. Enter:
2. rmlv <lvname>              <-- remove the unwanted logical volume.


Migrating PPs between disks:

checking the PPs of test1lv:
lslv -m test1lv
LP    PP1  PV1               PP2  PV2               PP3  PV3
0001  0001 hdisk6
0002  0002 hdisk6
0003  0003 hdisk6
0057  0057 hdisk6
0058  0058 hdisk6
0059  0059 hdisk6

the command: migratelp test1lv/59 hdisk7
(it wil migrate LP #59 to hdisk7)

in a for cycle:
for i in $(lslv -m shadowlv | grep hdisk1 | tail -10 | cut -c 2-4); do
migratelp shadowlv/${i} hdisk0


Once had a problem with an lv and its mirror copies:

root@bb_lpar: / # lsvg -l bbvg
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
0516-1147 : Warning - logical volume bblv may be partially mirrored.
bblv                jfs2       16      20      3    closed/syncd  /bb

root@bb_lpar: / # mirrorvg bbvg
0516-1509 mklvcopy: VGDA corruption: physical partition info for this LV is invalid.
0516-842 mklvcopy: Unable to make logical partition copies for

        logical volume.
0516-1199 mirrorvg: Failed to create logical partition copies
        for logical volume bblv.
0516-1200 mirrorvg: Failed to mirror the volume group.

root@bb_lpar: / # lslv -l bblv
0516-1939 : PV identifier not found in VGDA.

root@bb_lpar: / # rmlvcopy bblv 1 hdisk2
0516-1939 lquerypv: PV identifier not found in VGDA.
0516-304 getlvodm: Unable to find device id 0000000000000000 in the Device

        Configuration Database.
0516-848 rmlvcopy: Failure on physical volume 0000000000000000, it may be missing
        or removed.

The partial mirrored lps caused a big mess in VGDA and LVM, so the solution was the removal of these lps with a low-level command: lreducelv

1. checking the problematic lps:
root@bb_lpar: / # lslv -m bblv
LP    PP1  PV1               PP2  PV2               PP3  PV3
0001  0008 hdisk2
0002  0009 hdisk2
0003  0010 hdisk2
0004  0011 hdisk2
0005  0012 hdisk2
0006  0013 hdisk2
0007  0014 hdisk2
0008  0015 hdisk2
0009  0008 hdisk3            0016 hdisk2
0010  0009 hdisk3            0017 hdisk2
0011  0010 hdisk3            0018 hdisk2
0012  0012 hdisk3            0019 hdisk2
0013  0001 hdisk2
0014  0002 hdisk2
0015  0003 hdisk2
0016  0004 hdisk2

2. creating a text file with these wrong lps which will be used by lreducelv:
1st column: PVID of the disk with wrong lps (lspv hdisk2: 00080e82dfab25bc)
2nd column: PP# of the wrong lps (lslv -m bblv: PP2 column)
3rd column: LP# of the wrong lps (lslv -m bblv: LP column)

root@bb_lpar: / # vi partial_mir.txt
00080e82dfab25bc 0016 0009
00080e82dfab25bc 0017 0010
00080e82dfab25bc 0018 0011
00080e82dfab25bc 0019 0012

3. removing the partial mirror copies:
lreducelv -l <LV ID> -s <NUMBER of LPs> <TEXT FILE>

LV ID: 00080e820000d900000001334c11e0de.1 (lslv bblv)
NUMBER of LPs: 4 (wc -l partial_mir.txt)
TEXT FILE: partial_mir.txt

root@bb_lpar: / # lreducelv -l 00080e820000d900000001334c11e0de.1 -s 4 partial_mir.txt

Now the lvm deallocates all PP's of your partially mirror.

4. After these, lslv -m will show correct output, but LVCB or VGDA could still show we have 2 copies
root@bb_lpar: /tmp/bb # odmget -q name=bblv CuAt | grep -p copies

        name = "bblv"
        attribute = "copies"
        value = "2"
        type = "R"
        generic = "DU"

(We can see this paragraph only if there is mirroring, otherwise there will be no output of odmget command)

root@bb_lpar: /tmp/bb # getlvcb -AT bblv
         AIX LVCB
         intrapolicy = m
         copies = 1

(odmget shows we have 2 copies and getlvcb shows we have only 1 copy.)

Probably it is safer if we update both with the correct value:
putlvodm -c <COPYNUM> <LV ID>
putlvcb -c <COPYNUM> <LV NAME>

LV ID: 00080e820000d900000001334c11e0de.1 (lslv bblv)

root@bb_lpar: /tmp/bb # putlvodm -c 1 00080e820000d900000001334c11e0de.1
root@bb_lpar: /tmp/bb # putlvcb -c 1 bblv

source of this solution: http://archive.rootvg.net/cgi-bin/anyboard.cgi/aix?cmd=get&cG=73337333&zu=37333733&v=2&gV=0&p=



Anonymous said...

Very good stuffs

narayana said...

yep, Very good Stuff

aix said...

thanks :)

Anonymous said...

excellent info...keep up the gud work.....

aix said...


naresh said...

amazing work what u done boss

aix said...


Vasanth G said...

(AIX 6.1)

Rootvg have 2 disks(hdisk0 and hdisk1). current boot is hdisk0. only hd11admin and livedump resides in hdisk1.. can i move it to hdisk0?

by " migratepv -l hd11admin hdisk1 hdisk0" and "migratepv -l livedump hdisk1 hdisk0" will it works??

If possible can u plz ex-plain use of both LV's..

Vasanth G said...

Senario is that.. I am supposed to do TL upgrade for AIX 6.1 server.. Rootvg was mirrored with hdisk0 and hdisk1.. current boot is hdisk0..
LV's hd11admin and livedump was not mirrored. I unmirrored rootvg (unmirrorvg rootvg hdisk0 --- success). then trying to reduce rootvg hdisk1 (reducevg rootvg hdisk1)..
Warning : hd11admin and livedump will be deleted... (Y/N)... N

then later i tried me mirror back... but not happening.. throughing error...

so later i done multibos and completed TL upgrade.....

But now mirror not happening.. so i want to move hd11admin and livedump to hdisk0.. and reduce hdisk1 /add to rootvg and want to mirror it again.....

Also y those two LV's not mirrored before I unmirrored it.... I hope only sysdum in rootvg wont get mirrored?????

can u plz explain on this issue.. where i went wrong????

Advance Thanks..!!

aix said...


I checked 1 AIX server and these LVs (hd11admin and livedump) are mirrored in that server.

hd11admin: privileged processes can securely create temporary files there
livedump: this is the place where you can create a dump on a live system, without rebooting it.

The commands what you sent should work and I don't know why these LVs were not mirrorred earlier.

Hope this helps,

Juraj Bocinec said...

Hello, have you come across an issue when lslv reported only some of the information? If i run it under root i get all the information but other user has some information missing, for example:

LPs: ? PPs: ?

on other systems this works fine, even on 2nd node of the cluster. May this be some security setting in the AIX? But we didn't change anything in the environment settings. I have also checked LVCB and VGDA and they seem correct. Also ODM must be correct because i wouldn't get this info for root.

aix said...

Hi, strange, I've never seen this before...first ideas:
-do you experience this with other lvm commands? (i.e. lsvg)
-do you experience this for every lv? (if not do you see some logic?)
-do you experience this with smitty as well?

I'll think about that.

Juraj Bocinec said...

Hello, with other commands (lsvg, lspv) i get output, it only doesn't work for lslv command and for all LVs, even in different VGs than rootvg. This behaviour is the same with smit. I will try to arrange for reboot and see if it helps, it may as well be a bug in AIX.

aix said...

Hi, 2 things :)

1. This is written in man lslv:
"If the lslv command cannot find information for a field in the Device Configuration Database, it will insert a question mark (?) in the value field. ..."

So lslv will get info from ODM. If you check "ls -l /etc/objrepos", you could see if other user has read access to those files or not.

2. This is written in man lslv:
"The command attempts to obtain as much information as possible from the description area when it is given a logical volume identifier."

I'm not sure about that, but it seems that, if lv ideintifier is used it will get info from VGDA???
Probably you can give a try to it:
# lqueryvg -tAp hdiskX --> it will list lv identifiers as well
# lslv --> for example "lslv 00cebffe00004c000000010363f50ac5.2"

Please send some feedback if you could figure out something.

Juraj Bocinec said...

Hello, these data are not taken from ODM, because if i read data from VGDA with readvgda -l hdisk0 i get this info:

============= B: LV lvdump1 =============
LV IDENTIFIER: 00f620a400004c0000000136544024bd.18 PERMISSION: read/write
MAX LPs: 512 PP SIZE: 256 megabyte(s)
LPs: 30 PPs: CALC
STALE PPs: CALC BB POLICY: relocatable
Serialize IO ?: NO

as you can see data that are missing are not those that are stored in ODM but rather in VGDA and this seems to be correct. Even LVCB is correct if i check with getlvcb -AT lvdump1.

As for point 1 - i checked contents of /etc/objrepos on both cluster nodes and it's the same regarding permissions and ownership
As for point 2 - if i use LV identifier with lslv i still get question marks instead of full information.

I have opened PMR to IBM asking if this is a known bug. It's a possibility because here we use oslevel 6100-06-06-1140 with quite wild combination of efixes.

I'll let you know when i have some info from them.

Juraj Bocinec said...

Oops, seems i posted this as a comment rather than reply to proper thread, sorry for that.

Juraj Bocinec said...

Hello again, we have solved this problem. It turned out there have been wrong ownerships on several directories in / filesystem. So in case you come across this problem, check if your /usr or /etc is owned by correct user and not by some sap or oracle user.

aix said...

Thanks for the feedback...this was a strange issue, good to know this solution :-)

Anonymous said...

I have a scenario where i have deleted a file from the directory, but still the space was reclaimed to the file system.

Need your inputs about what might be the case of this.

aix said...

Hi, if you delete a file, while it is opened by a process its space will not free up.
Try this command: "fuser -dV "
It will shows deleted files (inode) with process ids which are open by a process (so its space could not be freed up). Solution: kill the process, wait for the process to finish or reboot the system.

Unknown said...

Hi, the LV in the rootvg hd5 is in closed/syncd state why?
All other LVs are in open/syncd including paging(hd6) also.
If we don't have mount to both LVs, but one is in Closed/syncd state and the other is Open/Syncd state.
Coule you Please explain.

aix said...

hd5 is the boot logical volume. It should not be in open state as you are not write in it regularly. It is used at boot time (or probably when you create the bootimage with bosboot command).

hd6 is the paging space. It is in open state, because system is using it, in case of memory shortage. If you create another paging space, you can play to activate or turn it off (swapon/spapoff command), so it can be in closed state if needed.

Anonymous said...

Hi, I always use your blog. Its v helpful. I want to reduce the size of dumplv. How do I do that? reducelv dumplv 6?


aix said...

Hi, thanks. I would delete that lv and recreate a new one.
More info: http://aix4admins.blogspot.hu/2011/06/aix-generates-system-dump-when-severe.html
(I've never heard about that command: reducelv...)

Anonymous said...

excellent information... it saves me time a lot while I work at my environment...

Unknown said...

Hi I have problem in one my volume groups.

I have 5 disks in the vg. after a reboot I could not mount the filesystems. it is throwing the error superblock dirty. I have ran fsck on the LV but still no luck.
compared both the secondary superblock and primary both are same. Is there any issue with log logical volume. If log logical volume corrupts will it effect my other LV's
I have tried to run logform on log LV but it is throwing me error"failure in logformat". My question is can I recreate log logical volume a new one.

aix said...

Hi, in the following link it is written, logform should be done on closed LVs:

As it is written above, if fsck was successful, then you are safe to do logform, or create a new log logical volume, otherwise filesystems can be corrupted. (And these actions can be done while filesystems are umounted.)

Unknown said...
This comment has been removed by the author.
Unknown said...

in VIO server i am facing problem with LVs in one of vg as bellow and needs help there how i can change LV STATE from closed/syncd to open/syncd, will be thankful for any suggestion
# lsvg -l diskvg
disklv0 jfs2 273 273 1 open/syncd N/A
disklv1 jfs2 273 273 1 closed/syncd N/A
disklv2 jfs2 273 273 1 open/syncd N/A
disklv3 jfs2 273 273 1 closed/syncd N/A
disklv4 jfs 273 273 1 closed/syncd N/A
disklv5 jfs 273 273 1 closed/syncd N/A
disklv6 jfs 273 273 1 closed/syncd N/A
disklv7 jfs 273 273 1 closed/syncd N/A
disklv8 jfs2 150 150 1 closed/syncd N/A
disklv9 jfs2 150 150 1 closed/syncd N/A
disklv10 jfs2 150 150 1 closed/syncd N/A

Anonymous said...

what is the use of jfs2 log?

Anonymous said...

as far as i know the jfs2 log partition host disk changes (it use a db for that) before physically write it no the disks.

Anonymous said...

Thanks excellent info.. I have fixed the issue

chandra said...
This comment has been removed by the author.
chandra said...

Hi can we reduce striped lv ?can you please explain the process

Anonymous said...

I have one VG who is in use by phisycal machine, but this machine crashed. So I need mount this VG in one Lpar. Is it possible?

NIXGURU said...

Had increased FS system size (sample_lv) on particular disks hdisk189 hdisk190 in a shared FS

but unfortunately given addnl size occupies the space on other disks hdisk78 hdisk40 too

In case, need to remove the addnl lv size occupied on hdisk78 hdisk40. How to achieve it. Pls advice.

lslv -m sample_lv|tail
1191 0121 hdisk78 0799 hdisk132
1192 0122 hdisk78 0298 hdisk40

Unknown said...
This comment has been removed by the author.
Anonymous said...

I would like to know how to create striped lv in aix ? How to convert existing lv to striped lv ?

Unknown said...

Hi,,In the LVM we have Only Increase the LV by using extendlv
there is no command to reduce the LV

Unknown said...

Can anyone tell how migratelp work with stripped logical volume ..itried but am getting below error
0516-818 migratelp: Striped logical volume orausrlv will not be migrated.
I need to change the volume group type.

inspiring youth said...

Whether you got any fix for this?