Volume Commands
| Logical Volumes | Physical Volumes |
|
|
| Volume Groups | Other Utilities |
|
|
|
Useful Information
|
|
Definitions
| Examples | What it means |
| PHYSICAL PARTITION (PP) | Smallest unit a PV is divided into (4 MB partition size) |
| LOGICAL PARITITION (LP) | One or more PPs. LP represents a mirrored copy of a PP. Up to two copies of a PP can be mirrored resulting in a LP count of three (2 mirrors plus original). |
| LOGICAL VOLUME (LV) | One or more PPs. A file system resides on top of an LV. Only one LV is mapped to a file system. A LV can’t span across a VG. Up to 255 LVs in a VG |
| VOLUME GROUP (VG) | One or more PVs. A collection of PVs that users view as a single oversized PV. A VG can consist of any mixture of physical disk types (size=320,355,400,670,800,857 MB), though performance is most consistent if devices of the same size are used in a single VG. Up to 32 VGs per system. |
| PHYSICAL VOLUME (PV) | One or more LVs. Represents a hard disk (hdisk0). |
| AREA (VGDA) | Information about all the LVs and PVs within a VG. First 64K of a PV is reserved for this area – defined in <sys/bootrecord.h>. The VGDA consists of
|
| AREA (VGSA) | Informations about which PPs are stale and which PVs are missing within a VG. The LVM and SCSI driver reserves somewhere between 7-10% of the available disk space for LVM maps, etc. |
Logical Volume Set-up
All system LVs (hd1..hd8, hd9var) should reside in the VG named rootvg, under one PV if possible. This will allow complete re-installation of the system from your ‘mksysb’ tape without affecting the application data that resides on your other VGs. There is no difference in response time between a single or multiple VGs. When an LV is accessed
- The ODM database (/etc/objrepos/*) is searched to determine which VG the LV belongs to.
- Then the VGDA for that VG is read to determine the physical placement
of the LV on that PV and ultimately the physical track and sector where the data resides.
A few notes about Mirroring
Mirrored LVs that generate lots of write I/O calls, will cause a disk performance penalty (such as paging LVs). For LVs that encounter heavy read I/O calls, disk performance is increased. Since the LVM (logical volume manager) driver keeps track of the location of each disk head, the disk arm closest to the data being requested will be issued the read request. Further, mirroring can only be performed within a single VG. NFS mounted file systems cannot be mirrored.
top of page
Steps required to re-import VG’s after a system re-install
When a system is re-installed, the disk drives may not be named in the same order as they originally appeared. If the system halts with the message ‘performing Auto varyon of Volume Groups’ on the console, perform these steps:
- Press CTRL-C to continue and login as root
- Export ALL non-root volume groups export <VGName>
- Shutdown and reboot the system shutdown -Fr
- Re-import non-root volume groups importvg -y <VGName> <PVName>
Steps required to replace a failing PV from a non-root VG
- Backup all filesystems found on the failing PV.
- lspv -l <PV> (lspv -l hdisk2) To determine which filesystem(s) are found on the PV in question.
- Find out how the LVs are laid-out on the PV so you will know how to re-create them when the time comes.
- lslv -m <LV> (lslv -m oracle) You will use the output of the lslv command to serve as a template for creating a map file for this LV later on.
- Unmount all filesystems on that PV. umount <FILESYSTEM_NAME> to unmount each filesystem from the PV in question.
- Remove all LVs found on that PV. rmlv <LV> (rmlv /oracle)
- Remove the questionable PV from the system. reducevg <VG> <PV>
- Remove the PV entry from the ODM database. rmdev -l <PV_NAME> -d (rmdev -l hdisk2 -d)
- Shutdown the system: Shutdown -F
- Remove the bad PV and install the new PV
- Add the new PV to the VG in question. extendvg <VG> <PV> (eg., extendvg datavg hdisk2)
- Re-create the LVs removed from the OLD PV to the NEW PV.mklv -y<LV> -m<MAP_FILE> <VG> <PP_NUM> <PV> (mklv -y oracle -m oracle.map oraclevg 200 hdisk2)The map file is assembled from the output generated from the lslv -m command in step 2 above. Do this for each LV that existed on the removed PV.
- Re-size the filesystems on the new PV. mkfs /dev/<LV> (mkfs /dev/oracle) Do this for each file system that existed on the removed PV.
- Perform a filesystem check before mounting it. fsck -f /dev/<LV> (fsck -f /dev/oracle)
- Mount all filesystems on that PV. mount <FILESYSTEM_NAME> (mount /oracle)
- Now restore the data you backed up
How to perform mirroring
- mklv
- mklvcopy
- synvg -l <LV>
How to move a PV to another SCSI controller
As long as all your doing is moving a PV to another SCSI adapter and not placing that PV in another VG, then just move the PV to the other SCSI adapter and reboot. When the machine comes back up and finds that the disk is no longer located in its previous slot, it finds the exact PVID of the disk on the other adapter and assumes the disk was moved. It then changes the ODM accordingly, and your back in business again.
How to mirror a boot logical volume
Each hard drive is a potential boot device. The bosboot command creates a bootable image in the BLV (boot logical volume), which is used to boot AIX. The first block (sector) on the disk is called the boot block or IPL record. In addition, NVRAM contains a list of boot devices which can be specified by the bootlist command. The boot device can be changed by using the bosboot and bootlist commands. The format for these commands follows:
bootlist -m normal hdisk0 for normal operations
bootlist -m service fd0 rmt0 hdisk0 for service operations
bosboot -u -d /dev/hdisk0 bootable image in BLV on hdisk0
The bosboot command puts a bootable image in the BLV that is used to boot the system. Also, the bosboot command puts the physical sector number of the beginning ofthe bootable image on this disk, into the boot block of the disk. Since only one PSN (that of the primary copy of the BLV) is stored, therefore all copies of the BLV must reside on the SAME physical partitions of their respective devices.
An example of a mirrored BLV with 3 copies follows:
blk XXX, where XXX is the starting physical sector number in hex, within the specified physical partition (PP) number.
| Copy 1 | Copy 2 | Copy 3 |
| hdisk0 | hdisk1 | hdisk2 |
| LP 1: PP 1(blk 200 ) | LP 1: PP 6(blk C200) | LP 1: PP 4(blk 8200) |
| LP 2: pp 2(blk 2200) | LP 2: PP 7(blk E200) | LP 2: PP 5(blk A200) |
To use hdisk0 as the boot device, specify the following: bosboot
-a -u -d /dev/hdisk0
The IPL record on hdisk0 indicates the boot image starts at PSN (physicalsector number) 200. Now, the system can be booted using drive hdisk0.
To use hdisk1 as the boot device, issue the following: bosboot -a -u -d /dev/hdisk1
Because the bosboot program only looks for the PSN of the first copy, the IPL record indicates the starting PSN for the boot image as 200 instead of the correct C200. Attempts to boot with hdisk1 as the boot device will fail.
To mirror the BLV and get around this problem, do the following. Insure that all the copies occupy the same physical partitions on each device. It is not important which partitions the BLV uses, but all copies must use the same relative positions on the disk device. So, the configuration should be:
| Copy 1 | Copy 2 | Copy 3 |
| hdisk0 | hdisk1 | hdisk2 |
| LP 1: PP 10(blk 20200) | LP 1: PP 10(blk 20200) | LP 1: PP 10(blk 20200) |
| LP 2: pp 11(blk 22200) | LP 2: PP 11(blk 22200) | LP 2: PP 11(blk 22200) |
To move individual partitions around and keep them in sync, use the lmigratepp command.
To find available physical partitions on a disk, use lspv -m hdisk? Take the output of this command and choose two physical partition that are allocated/free on all the target disks and use these partitions to create your BLV image on multiple disk drives.
If your mirroring, make sure that PTF U407433 is installed. This allows you to disable the QUORUM feature. When one disk dies, the other disk will take over without checking to see if the quorum is still meet. (chvg -Qn rootvg)
When a write is performed to a disk containing mirrored copies, all copies are written simultaneously in parallel mode, and each is written sequentially in sequential mode.
Should the system crash while parallel writes are being performed to mirrored copies of the data, inconsistencies may exist between the data which was actually written to the different copies. To protect against this, the Mirror Write Consistency Cache was developed to write a record to the disk each time a mirrored write is in progress, so that when the system is rebooted, a record will show that possible inconsistencies may exist, and the data from the first physical partition is rewritten to all other physical partition copies. However, by enabling the Write Consistency Check, the penalty you pay is having to do an extra read/write when doing I/O. When this feature is disabled, if the system goes down because of power failure or system crash, you will need to MANUALLY perform a syncvg when the system is rebooted.
The jfslog is used to keep a record of file system metadata (superblock, inode, directories, etc) and also ensures the integrity of the file system.
The impact of losing the PV containing the jfs log will be quite serious. All file systems using that log will become unavailable.
bootinfo
| Examples | What it does |
| /usr/sbin/bootinfo -b | Displays the boot PV device (hdisk0). The boot PV does NOT always refer to hdisk0. The boot PV will ALWAYS be the PV that contains the LV named hd5. The LV hd5 contains the boot logical volume (BLV), which contains the information needed to boot the system into a single/multi-user state |
| bootinfo -a | hdisk1 320 4 8 00-01-00-00 |
chlv
Changes the attributes for an LV
| Examples | What it does |
| chlv -x 256 hd1 | When creating large LVs or extending an existing LV to over 512MB (assuming PP SIZE=4) in size, the following error message will be displayed: 516-787 extendlv: Maximum allocation for logical volume h1 is 128. To resolve this problem, perform the above command where 256 represents the MAXIMUM number of logical partitions that can be allocated for that LV. This command can be executed while the file system (residing on top of the LV) is mounted. |
| chlv -n informixlv lv00 | Changes the name of LV from lv00 to informixlv. If there is a filesystem mounted on top of that LV, the file system must be unmounted and the LV must be in a closed state for this command to work. chlv -n <NEW LV> <OLD_LV> |
cplv
Copy the contents from one LV to a new or existing LV
| Examples | What it does |
| cplv -e newroot hd4 | Copies the LV hd4 to an LV named newroot. If newroot doesn’t exist, it will be created. If newroot is smaller than hd4, the extra PPs from hd4 won’t be copied to the desintation LV newroot |
chpv
Change the characteristics of a physical volume
| Examples | What it does |
| chpv -a n hdisk2 | Prohibits the allocation of additional PPs on PV hdisk2 |
| chpv -vr hdisk2 | Temporarily removes a PV from a VG (normally used for maintenance) This command removes the VGDA and VGSA copies from the PV, thereby affecting the number of copies required for a quorum. |
| chpv -va hdisk2 | Returns an inactive PV back to the VG |
chvg
| Examples | What it does |
| chvg -Qn rootvg | This will turn quorum checking off (default is on). Afterwords, the volume group must be varied off and back on again to cause the change to take effect. In the case of rootvg, this means a reboot. |
exportvg
Used to export a VG from one system so that it can be imported by another. This command will erase all data referencing the VG being exported from the ODM database, but won’t remove this information from the VGDA (undefines the VG on the system). The information deleted from the ODM but not the VGDA is the LV and VG entries.
To manually transport a VG between systems, the normal process is to varyoff and export the volume group on System A:
varyoffvg VG
exportvg VG
Then move the drives to System B followed by importing them and finally varying them on:
importvg -y VG PV
varyonvg VG
exportvg vg2
importvg -y vg2 hdisk1 #hdisk1 is PV that belongs to VG named vg2
varyonvg vg2
The above steps can be used to correct the ODM when it is not in sync with the VGDA
extendvg
Add a new physical drive to a volume group
| Examples | What it does |
| extendvg datavg hdisk3 | Adds the PV hdisk3 to VG datavg. This increases the size of the VG by adding one or more PVs. |
getlvodm
| Examples | What it does |
| getlvodm -u rootvg | Will determine whether the ODM or VGDA has the correct copy of the VGDA. If the above command returns the character ‘y’ for the VG specified, then the ODM database is correct and the VGDA is out-of-sync. To correct the situation when the VGDA doesn’t have a good copy, perform the following steps:
|
importvg
Used to import a VG from a system that exported it. This command will restore the ODM database from information read from the VGDA. When a VG is imported, /etc/filesystems will be updated with any entry points needed for those LV’s and mount points not currently defined.
ipl_varyon
| Examples | What it does |
| ipl_varyon -i | Indicates which PV is your BOOT drive |
lqueryvg
| Examples | What it does |
| lqueryvg -p hdisk0 -v | List the VG id in which the PV hdisk0 resides |
| lqueryvg -p hdisk0 -L | List all the LV ids/names in the VG where PV hdisk0 resides |
| lqueryvg -p hdisk3 -P | Lists all the PV ids that reside in the VG where hdisk3 resides |
lslv
List characteristics about a logical volume
| Examples | What it does |
| lslv hd3 | Display attributes of the LV hd3 |
| lslv -l hd3 | List distribution of where LV hd3 resides on PV hdisk1 |
| lslv -m hd3 | List distribution of PPs where LV hd3 resides on PV hdisk1 |
- MAX Lps: If LV created is larger than 512 MB (128 * 4), then this field needs to be upped by the following formula: (LV size in megabytes) / PP size = MAX LP count 900 MB / 4 =
225 The command to change the LP count to 225 for an LV named pick is: chlv -x 225 pick - COPIES:
- value is 1= original copy
- value is 2= first mirrored copy
- value is 3 = second mirrored copy
- STALE PPs: If COPIES > 1 and STALE PPs > 0, means that a mirrored LP is not available or current with other LPs.
- INTER-POLICY:
- If set to MIN, an LV will only reside on 1 drive
- If set to MAX, an LV can span multiple LVs. Distributes an LV among more than 1 PV.
- INTRA-POLICY: Has 3 values (edge, middle, center). When an LV is created, it will be assigned 1 of the 3 allocation strategies listed above.
- EFFICENCY: Represents the efficency with which PPs are allocated based on the 3 possible states of the intra-policy.
- RELOCATABLE : If yes, then the ‘reorgvg’ command is allowed to move the LV to a new position on the current PV or be placed on another PV.
- SCHEDULING POLICY: If set to PARALLEL, insures writes to mirrored copies are performed to seperate PVs in parallel.
- WRITE-VERIFY: If set to NO, will not perform a follow-up read to each write for verification.
- MIRROR WRITE CONSISTENCY: When enabled, suffer a 20% performance penality. Use the syncvg -v <VG> command to resync disk drives in a VG that loses a PV.
lsps
List characteristics of paging space(s).
PAGING SPACE LOW
messages will be generated when 512 pages remain free in the pool of free pages. Processes will be terminated when only 128 pages of free memory are left.
AIX determines which users have the most page space allocated to them and selects those processes for termination. All real memory allocated to a process will have a backing store of equal size (for every page of real memory allocated, there will be a page of disk space from paging space allocated)
Its recommended that the first paging space (/dev/hd6) be larger, since this one is brought on sooner than the rest, resulting in being more full than the others.
Thrashing should not be confused with the problem of low paging space. Low paging space is the condition in which the amount of paging space is insufficient. Thrashing is the condition in which the amount of RAM is insufficient. Low paging space involves the consumption of disk space; thrashing involves the consumption of RAM and disk I/O.
Example:lsps -a (Display attributes of all paging spaces)
LV hd6 is the default paging space. If more than one paging LV is defined, hd6 will always have a higher percentage of utilization since this is the first paging LV turned on at boot time. Once all the other paging LVs have been swapped on, paging is allocated on a round robin basis – four pages (pagesize is 4k ) at a time.
80% (MAXPERM) of real memory is to be used by persistent storage. Persistent storage is information that is not paged to the page space (/dev/hd6) but rather is paged to the physical volume where that file resides.
lspv
List charactertistics of a physical volume
| Examples | What it does |
| lspv hdisk0 | Stale partitions refers to mirroring. If the PV has no mirrored LPs, then the value for this field is zero. |
| lspv -l hdisk0 | Display distribution of what LVs reside on the PV named hdisk0 |
| lspv -p hdisk0 | Display distribution of PPs for each LV that resides on the PV named hdisk0 |
lsvg
List characteristics about volume groups
| Examples | What it does |
| lsvg rootvg | Display attributes for VG rootvg |
| lsvg -p rootvg | Display PV distribution about VG rootvg |
| lsvg -o | Lists all active VGs in the system |
migratepv
Moves one or more LVs to one or more PVs. If ‘/dev/hd5’ is moved to another drive, a spcial step is required, else the system will not boot the next time it’s rebooted.
| Examples | What it does |
| migratepv hdisk0 hdisk1 | Moves all LVs from hdisk0 to hdisk1 |
| migratepv -l hd1 hdisk2 hdisk1 | Copies all PPs for LV hd1 from hdisk2 and places them on a PV named hdisk1 |
mklv
Creates a logical volume on a physical volume
| Examples | What it does |
| 1) mklv -y hd7 -t sysdump -a e rootvg 2 hdisk02) sysdumpdev -P -p /dev/hd7 |
The first command will create a LV dump device named hd7 that consists of 2 PPs located on the edge of PV hdisk0. The second command will assign the system dump device to LV /dev/hd7. |
| 1) mklv -y hd5 -t boot -a e rootvg 2 hdisk2OR1) migratepv -l hd5 hdisk0 hdisk2
2) bosboot -a -l /dev/hd5 -d /dev/hdisk2 3) bootlist -m normal hdisk2 |
Creates and updates a new boot logical volume (hd5) on PV hdisk1. When you move the /blv (boot) file system, you MUST change the disk from which the system tries to boot from to NORMAL mode. |
mklvcopy
Makes a mirrored copy of an LV. Note that this command will allocate PPs for the next copy, but the data within is not updated. This must be performed by the syncvg command.
| Examples | What it does |
| 1) mklvcopy hd1 2 hdisk12) mklvcopy hd2 2 hdisk13) mklvcopy hd3 2 hdisk1
4) mklvcopy hd4 2 hdisk1 5) mklvcopy hd5 2 hdisk1 6) mklvcopy hd6 2 hdisk1 7) mklvcopy hd7 2 hdisk1 8) mklvcopy hd8 2 hdisk1 9) syncvg -v rootvg |
Will mirror the operating system so that the system may be booted from either disk in the case of a disk drive failure. The syncvg command will insure that all LVs just copied will be in synchronized with each other.
|
| 1) mklvcopy -m lv00.map lv00 22) syncvg -l lv00 | When creating the LV named lv00, use the map file named lv00.map. Using the syncvg command will update the mirror copy. |
putlvodm
Reads LV data from the command line and writes it to appropriate ODM (Object Data Manager) class fields.
| Examples | What it does |
| putlvodm -K `getlvodm -v rootvg` | Unlocks a VG so that the LVM commands can access or change information about a particular LVM device.If the message 0516-366 lsvg: Volume group rootvg is locked is ever seen, the above command will unlock the VG in question. |
redefinevg
Determines which PVs belong to the specified VG and re-enters this information into the ODM. This command is typically used to fix inconsistencies in the ODM database by reading a copy of the VGDA and recreating the ODM entries as needed.
| Examples | What it does |
| redefinevg -d hdisk0 rootvg | Updates the ODM for a specific VG with the information stored in the VGDA |
reducevg
Removes one or more PVs from a VG
| Examples | What it does |
| reducevg rootvg hdisk1 | Removes the PV hdisk1 from the VG rootvg. |
| reducevg -df rootvg hdisk2 | Removes hdisk2 from the VG rootvg and all LVs on that PV that weren’t previously removed. |
restbase
Reads the base customized information from the boot image and restores it in the ODM
rmlv
Removes a logical volume from a volume group
| Examples | What it does |
| rmlv lv00 | Removes the LV lv00 from a VG and restores that space back to the free DASD list. The amount of free disk space returned can be verified by executing the lsvg rootvg command before the rmlv command is executed and after it.
|
rmlvcopy
Removes logical partition (mirrored) copies. If no PV named is included with this command, the last copy created will be removed first.
| Examples | What it does |
| rmlvcopy lv00 2 | Removes both copies of the LV lv00 |
| rmlvcopy lv00 1 hdisk2 | Only the copy (LV:lv00) that exists on PV hdisk2 is removed. |
savebase
Reads the base customized information from the ODM and restores it to the boot device (hd5).
schedtune
A memory load algorithm that detects when the system is thrashing and suspends active processes and delays the initiation of new processes for a period of time. Since the suspended processes are not scheduled, their pages in RAM are not being referenced, and are freed for other processes to use.
When thrashing stops, the suspended processes are gradually activated again. The result is that the performance is much more predictable and constant when RAM is in demand. Schedtune is part of the lpp named ‘bosadt.lib.obj’ or PTF U412059. AIX does’t allocate a page until you actually attempt to use it.
| Examples | What it does |
| schedtune -h 0 | Disables memory load control. Memory load control is ENABLED by default. |
| schedtune | Determine current settings for load control. |
| schedtune -D | Resets memory load control to its default characteristics |
syncvg
Synchronizes stale partitions within VG. syncvg is automatically run when the VG is varied on (‘varyonvg’ command).
| Examples | What it does |
| syncvg -v rootvg | Synchronizes stale partitions on any PV that belongs to VG rootvg. |
| syncvg -l lv00 | Synchronizes the LV lv00 so that all copies are identical |
synclvodm
Will read the VGDA from the PV specified and update the ODM database. This command is typically used to fix inconsistencies in the ODM database, by reading a copy of the VGDA and recreating the ODM entries as needed.
| Examples | What it does |
| synclvodm rootvg hd1 | Rebuilds the ODM database for a LV hd1, by reading the VGDA. |
sysdumpdev
Operations performed on the system dump device
| Examples | What it does |
| sysdumpdev -p sysdumpnull | Turns off the dump device |
| sysdumpdev -p hd7 | Reactives the dump device |
| updatevg rootvg | Resynchronizes the VG information in the ODM |
Takes off-line a VG and all associated file systems and LV’s. If a file system or LV is still mounted or open when this command is executed, the command will fail. A VG that has an active paging LV cannot be varied off or exported.
Use the chps -an <PAGE_LV> to disable the paging LV followed by rebooting the system.
Must umount all file systems on each PV that belongs to a VG before it can be varyed-off
| Examples | What it does |
| 1) umount /oracle2) varyoffvg oracle | Varys-off ALL PVs associated with the VG named oracle. Essentially makes that VG inaccessible |
varyonvg
Activates a VG. Takes the information stored in the ODM database and updates the kernel.
| Examples | What it does |
| varyonvg oracle | Activates the VG named oracle and makes accessible any LV and/or file system that belongs in that VG |
| varyonvg -m1 oracle | Will insure the ODM database matches the attributes stored in the VGDA (syncs VGDA to ODM) and reports the status of all PVs. |
| varyonvg -f oracle | Used if the VG attempting to be varied on was not properly exported from another system, due to a system crash or some similiar instance. This force option is only needed when there is a problem with the VGDA on the imported VG |