LV

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:

LOGICAL VOLUME

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
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes
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
UPPER BOUND:    2

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
test1lv:/home/test1fs
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
done

------------------

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

root@bb_lpar: / # lsvg -l bbvg
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
bblv:/bb
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

CuAt:
        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>

COPYNUM: 1
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=

------------------