AIX Ver. 4 SysAdmin IV:Storage Management (Unit 6) – LVM Fundamentals (2 of 2)

LVM – Logical Volume Manager

Limits of VG Growth
——————————-
Limit type 1: PV size in relation to VGs PP size
– A PV may not have more than Factor * 1016 PPs
– The PP size is the same for all disks and can’t be changed for existing VGs.
– Consequence: A disk may be too large for an existing VG.
– Remedy: Use chvg -t with a larger factor value.

Limit type 2: PP map too small (“out of descriptor space …”)

The size of the PP map is calculated at VG creation time:

Size = Max PVs * PPs_per_PV / Factor

MaxPVx = option -d (default: 32 | 128 | 1024)
Factor = option -t (default: 1)

PPs_per_PV = (MaxPVsz / PPs) * Factor
MaxPVsz = Option -m
or 1016 if option -m was omitted
PPsz = option -s (default: 4)

Big VGs
—————-
Introduced with AIX 4.3.2
Advantages:
– 128 PVs per FG (1024 in future with giant VGs)
– 511 LVs per VG
– Existing VGs can be converted (chvg -B requires 1-2 free PPs per PV)
– Can help in conjuction iwith option -t to add large disks to existing VGS
– LVCBs are part of the VGDA (no more accidential overwriting!)
– importvg -R restores owner, group and permissions of raw LVs

Disadvantages:
– Conversion into big VGDA is a one way process
– Not backward compatible
– Some LVM commands take more time

Varying On a Volume Group
—————————————–
Command:
varyonvg [ -p ] [ -f ] [ -n ] [ -c ] [ -b ] [ -u ] VGname

Description:
– The LVM tries to read all VGDAs in the VG
If -p has been given, all PVs must be availabel for varyonvg to succeed.
– Unless -f has been specified, quorum is checked.
– If the requirements of -p or quorum are met, varyonvg continues
– If the VGDAs differ, the latest intact VGDA is used to overwrite all others.
– The VGs disks are reserved except with -u or -c
Option -b (break) removes reservation for an active VG.
– The mapped file /etc/vg/vgVGID is created.
– The LVs (/dev/LVname and /dev/rLVname) become accessible.
– syncvg is started as a background process unless -n has been specified.
– -c performs a concurrent varyon (for Oracle Parallel Server with HACMP).

The Logical Volume Control Block (LVCB)
————————————————————-
getlvcb -AT hd2

Intrapolicy:
Edge, Middle, Center, InnerMiddle, InnerEdge
Interpolicy:
Minimum, Maximum

Interaction of LVM and ODM (1 of 2)
—————————————————-
VGDA and LVCBs contain a VGs complete description
The ODM keeps a partial copy of this information as:
– PVs, VGs and LVs are devices and therefore need an ODM representation
– Accessing the on-disk structures can be time-consuming
A few data elements are contained in the ODM only.
There are three layers of LVM commands in AIX:
1. High Level Commands <--> ODM
– Many are scripts which run in SMIT (ex. mkdev)
2. Intermediate Level Commands <==>ODM
– Go through the ODM
3. Low Level Commands – PVs
– Go directly to the device

Interaction of LVM and ODM (2 of 2)
—————————————————-
ODM – /etc/filesystems (importvg, exportvg)
VGDA – LVCB (change via low-level commands)

mkvg – make a volume group
extendvg – extend a volume group
mklv – make a logical volume
crfs – create a file system
chfs – change a file system
rmlv – remove a logical volume
reducevg – removes a physical volume from the volume group

Standard importvg Command
——————————————-
Changes:
– The settings for auto-varyon and quorum check are preserved.
– The VG must be varied on in order to run chvg -a {y|n} -Q {y|n}

Additions:
– -n :No varyon; does not perform a regular varyonvg and leaves the VG varied off after import
– -F :Fast; omits cross-check of all available disks
– -R :Restore: recreates owner, group and permissions of LV devices if they have been set with chlv (Big VGDA only).

Hints:
– -n is intended for newly importing HACMP VGs and has the same prerequisites as improtvg -L (see next foil).
– -F should not be used when defects in the ODM or VGDAs seem probable.
– -R can be combined with -L.

importvg -L Command (>= AIX 4.2.1) L=Learn option
—————————————————————————
Facilitates online changes to HACMP VGs:
– Regular importvg not possible because of disk reservation.
– Would require a maintenance window for exportvg / importvg on node B

– Works in cooperation with varyonvg -b -u -n SharedVG on node A.
– HACMP 4.3 and above automate this process via C-SPOC (smit).

Updating a Shared VG Definition (1 of 2)
———————————————————–
PVID -hdisk relations must be identical on both nodes.
Node A (has the shared VG varied on):
– Make the necessary changes to the VG.
– Update the HACMP VG timestamp (suppresses “Lazy Update”):
/usr/sbin/cluster/utilities/clvgdats /dev/hdiskN >
/usr/sbin/cluster/etc/vg/VGname
– varyonvg -b -u -n VGname

Node B:
– importvg -L VGname hdiskN
– Update the HACMP VG timestamp (suppresses “Lazy Update”):
/usr/sbin/cluster/utilities/clvgdats /dev/hdiskN >
/usr/sbin/cluster/etc/vg/VGname

Node A:
– varyonvg -n VGname

Updating a Shared VG Definition (2 of 2)
———————————————————–
Wrong procedure:
ODM Node A:
1. hdiskN none
2. add disk to VG:
hdiskN ######### XYvg

ODM Node B:
1. hdiskN none
2. (no action) hdiskN none
3. importvg -L (even within C-SPOC) fails!

Correct procedure:
ODM Node A:
1. hdiskN none
2. assign a PVID explicitly
chdev -l hdiskN -a pv=yes
hdiskN ##### None
4. add disk to VG:
hidskN ###### XYvg

ODM Node B:
1. disk is still unknown
3. execute cfgmgr or mkdev:
hdiskN ###### None
5. importvg -L:
hdiskN ###### XYvg

The exportvg Command (Deletes VG definition from ODM)
————————————————————————————
Syntax:
exportvg VGname

Description:
– The VG must have been varied off before.
– The system deletes the VGs definition out of the ODM and /etc/filesystems
– VGDA and LVCBs are not changed
– It is possible to export a VG even if the disks are no longer available

LVM Data Stored in the ODM (Object Classes)
——————————————-
Cu – Custom Attributes

CuDv (all: existence, state)
CuDvDr (all: name –> major#, minor#)
CuAt (PVs: name –> PVID, attribute1…)
(VGs: name –>VGID, member PVID, auto_on, quorum check)
(LVs: name –> attribute1…)
CuDep (VGs: name –> memeber LV)

ODM-Related LVM Problems
——————————————
Recap: How Do High-Level Commands Work?
– High-level commands update the ODM after having made the changes to the VG itself.
– Signal handlers can clean up after an interruption.
– A locking mechanism blocks other commands while a change is in progress

What Can Cause Problems?
– kill -9, shutdown or a system crash
– Improper use of intermediate or low-level commands
– Hardware changes not accompanied by administrator’s action

When removing a disk from the system run the following commands.
reducevg (removes information about the disk from the LVM)
rmdev -dl (removes information about the disk from the ODM)

Troubleshooting ODM Problems
———————————————–
If the VG can be varied off
– Write down the VGs name and major number
– Identify at least one intact disk of the VG.
– exportvg VGname
– importvg -V MajorNum -y VGname hdiskX
– Check settings for quorum and auto varyon and device permissions

If the VG must remain active (for example, rootvg)
– Write down the VGS name and major number
– Identify at least one intact disk of the VG
– Export the VG “by the backdoor” using odmdelete
– Re-import the VG (may produce warnings, but will work)
– It is not necessary to unmount a file system or stop processes.

Note: rvgrecover (use when working on rootvg since you can’t vary off the rootvg while running)

LAB 4 – LVM Fundamentals
——————————————
1. Create a volume group
Find unallocated disks
lspv (displays the physical volumes)
smit mkvg
Enter a VG lab4vg
Enter PPs = 16 (press enter)

lspv (should see new VG lab4vg)

2. Create LV in new lab4vg
smit mklv
enter VGname lab4vg (press enter)
enter LVname lv_lab4
enter LPs = 2 (press enter)

Create a Raw LV
smit mklv
enter VGname lab4vg (press enter)
enter LVname lv_raw
LV Type: Raw

7. Look in the ODM
odmget -qname=lv_lab4 CuAt

8. Create a new Journaled File Sytem and add it to new LV
smit crjfslvstd
enter lv_lab4
enter mount point /home/fslab4 (press enter)

9. Repeat ODM query again
odmget -qname=LVname CuAt
See additional information about the new filesystem just added.

10. Mount the new filesystem
df
mount /home/fslab4
df

11. Why does it take time? It was the first one and it created a log
lsvg -l lab4vg
Log created was loglv00

Rename the log
smit chlv
select Rename
enter current loglv00
enter new name lab4log (press enter)
Won’t rename because the file system is mounted
umount /home/fslab4 (unmount the file system)
df (check mount)
then retry rename above

Have to change the name of the log file in this filesystem
vi /etc/filesystems
filesytem is listed at the bottom of the file
change it from loglv00 to lab4log

lsvg -l lab4vg
mount /home/fslab4
df

Lab Part 2
—————-
umount /home/fslab4
varyoffvg lab4vg
exportvg lab4vg
lspv (lab4vg VG is not displayed)
importvg -y lab4vg hdisk4
lspv (lab4vg VG is now displayed)

15. Look at settings for quorum and autovaryon
smit chvg
enter VGname

16. Disable autovaryon so another system can use it

Lab Part 3
—————-
Convert VG to Big format
lsvg -o (It is varied on)
smit lsvg
List the contents of a volume group
chvg -B lab4vg
lsvg lab4vg

CheckPoint Questions
———————————
1. How many disks are needed for a striped mirrored LV? Two for striping, two more to mirror
2. PV identifiers are programmed into the disk’s firmware by the factory? False
The 32 PVID gets written on the disk when added to a VG
3. Give the maximum number of PVs resulting from
a. mkvg -d 4 -y testvg1 hdiskx (4 disks)
b. mkvg -y testvg2 hdiskx (32 disks)
c. mkvg -t 2 -y testvg3 hdiskx (16)
d. mkvg -B -t 4 -y testvg4 hdiskx (32)
4. A volume group has been imported into node B some time ago
Which command will update the VG definition?
importvg -L VGname hdiskN
5. What is the simplest method to solve ODM-related LVM problems?
Use varyoffvg, exportvg, importvg commands
Use rvgrecover for rootvg so that you don’t have to shut the system down

Leave a Reply

Your email address will not be published. Required fields are marked *

*