6.1 Logical Volume Storage Concepts

6.2 Logical Volume Manager

The set of operating system commands, library subroutines, and other tools that allow you to establish and control logical volume storage is called the Logical Volume Manager (LVM). The LVM controls disk resources by mapping data between a more simple and flexible logical view of storage space and the actual physical disks.

6.2.1 LVM Configuration Data

The data that describes the components of the LVM is not kept in one place. It is important to understand that this descriptive data on volume groups, logical volumes, and physical volumes is kept in several places. Object Data Manager (ODM) Database

The ODM database is the place where most of the AIX V3 system configuration data is kept. The ODM database contains information about all configured physical volumes, volume groups, and logical volumes. This information mirrors the information found in the VGDA. For example, the process of importing a VGDA involves copying the VGDA data for the imported volume group into the ODM. When a volume group is exported, the data held in the ODM about that volume group is removed from the ODM database.

The ODM data also mirrors the information held in the Logical Volume Control Block. Volume Group Descriptor Area (VGDA)

The VGDA, located at the beginning of each physical volume, contains information that describes all the logical volumes and all the physical volumes that belong to the volume group of which that physical volume is a member. The VGDA is updated by almost all the LVM commands. The VGDA makes each volume group self-describing. An AIX system can read the VGDA on a disk, and from that, the system can determine what physical volumes and logical volumes are part of this volume group.

Each disk contains at least one VGDA. This is important at vary on time. The time stamps in the VGDAs are used to determine which VGDAs correctly reflect the state of the volume group. VGDAs can get out of sync when, for example, a volume group of four disks has one disk failure. The VGDA on that disk cannot be updated while it is not operational. Therefore, you need a way to update this VGDA when the disk comes online, and this is what the vary on process will do.

The VGDA is allocated when the disk is assigned as a physical volume (with the command mkdev). This just reserves a space for the VGDA at the start of the disk. The actual volume group information is placed in the VGDA when the physical volume is assigned to a volume group (using the mkvg or extendvg commands). When a physical volume is removed from the volume group (using the reducevg command), the volume group information is removed from the VGDA. Volume Group Status Area (VGSA)

The VGSA contains state information about physical partitions and physical volumes. For example, the VGSA knows if one physical volume in a volume group is unavailable.

Both the Volume Group Descriptor Area and the Volume Group Status Area have beginning and ending time stamps that are very important. These time stamps enable the LVM to identify the most recent copy of the VGDA and the VGSA at vary on time.

The LVM requires that the time stamps for the chosen VGDA be the same as those for the chosen VGSA. Logical Volume Control Block (LVCB)

The LVCB is located at the start of every logical volume. It contains information about the logical volume and takes up a few hundred bytes.

The following example shows the use of getlvcb command to display the information held in the LVCB of logical volume hd2:

# getlvcb -TA hd2 
intrapolicy = c
copies = 1
interpolicy = m
lvid = 00011187ca9acd3a.7
lvname = hd2
label = /usr
machine id = 111873000
number lps = 72
relocatable = y
strict = y
type = jfs
upperbound = 32
fs = log=/dev/hd8:mount=automatic:type=bootfs:vol=/usr:free=false
time created  = Tue Jul 27 13:38:45 1993
time modified = Tue Jul 27 10:58:14 1993

6.2.2 Disk Quorum

Each physical disk in a volume group has at least one VGDA/VGSA. The number of VGDAs contained on a single disk varies according to the number of disks in the volume group as shown in the following example:

Single PV in a volume group
Two VGDAs on one disk.
Two PVs in a volume group
Two VGDAs on the first disk, one VGDA on the second disk.
Three or more PVs in a volume group
One VGDA on each disk.

A quorum is a state in which 51 percent or more of the physical volumes in a volume group are accessible. A quorum is a vote of the number of Volume Group Descriptor Areas and Volume Group Status Areas (VGDA/VGSA) that are active. A quorum ensures data integrity in the event of a disk failure.

When a volume group is created onto a single disk, it initially has two VGDA/VGSA areas residing on the disk. If a volume group consists of two disks, one disk still has two VGDA/VGSA areas, but the other disk has one VGDA/VGSA. When the volume group is made up of three or more disks, then each disk is allocated just one VGDA/VGSA.

The Figure 37 shows that the quorum is lost when enough disks and their VGDA/VGSA areas are unreachable so that a 51% majority of VGDA/VGSA areas no longer exists.

Figure 37: Disk Quorum

When a quorum is lost, the volume group varies itself off so that the disks are no longer accessible by the Logical Volume Manager (LVM). This prevents further disk I/O to that volume group so that data is not lost or assumed to be written when physical problems occur. Additionally, as a result of the vary off, the user is notified in the error log that a hardware error has occurred and service must be performed.

This has implications when you want to use disk mirroring in order to ensure high availability. In a two disk mirrored system, if the first disk fails, then you have lost 66 percent of your VGDAs, and the entire volume group becomes unavailable. This defeats the purpose of mirroring. For this reason, three or more (and generally an odd number) disk units provide a higher degree of availability and are highly recommended where mirroring is desired.


There is the ability to turn off disk quorum protection on any volume group. Turning off quorum protection allows a volume group to remain online even when a quorum or majority of its VGDAs are not online. This would allow the volume group to remain online in the situation described previously. This capability provides for a less expensive mirroring solution but does carry the risk of data loss as, after a disk failure, data is accessible but no longer mirrored.

6.2.3 Disk Mirroring

Disk mirroring is the association of two or three physical partitions with each logical partition in a logical volume. When the data is written onto the logical volume, it is also written to all the physical partitions that are associated with the logical partition. Therefore, mirroring of data increases the availability of data.

AIX and the logical volume manager provide a disk mirroring facility at a logical volume level. If mirroring is established, this can be done when a logical volume is created.

The mklv command allows you to select one or two additional copies for each logical volume. Mirroring can also be added to an existing logical volume using the mklvcopy command.

The following mirroring factors can further improve the data availability: The mirrorvg Command

The mirrorvg command mirrors all the logical volumes on a given volume group. This same function may also be accomplished manually if you run the mklvcopy command for each individual logical volume in a volume group. As with mklvcopy, the target physical drives to be mirrored with data must already be members of the volume group. This command only applies to AIX Version 4.2.1 or later.

The following is the syntax for the mirrovg command:

mirrorvg [ -S  | -s ] [ -Q ] [ -c Copies] [ -m  ] VolumeGroup [ PhysicalVolume .. ]

By default, mirrorvg attempts to mirror the logical volumes onto any of the disks in a volume group. The mirrorvg command mirrors the logical volumes using the default settings of the logical volume being mirrored. If you wish to violate mirror strictness or affect the policy by which the mirror is created, you must execute the mirroring of all logical volumes manually with the mklvcopy command.


The mirrorvg command may take a significant amount of time before completing because of complex error checking, the number of logical volumes to mirror in a volume group, and the time to synchronize the new mirrored logical volumes.

Alternatively, you can also use the SMIT fast path command, smitty mirrorvg, to do the mirroring of volume groups.

The following examples show the use of the mirrorvg command: Rootvg Mirroring

When the rootvg mirroring has completed, the following three tasks must be performed.

The bosboot command creates a boot file (boot image) from a RAM (Random Access Memory) disk file system and a kernel. The bosboot command is required to customize the bootrec of the newly mirrored drive.

The bosboot command always saves device configuration data for disk. It does not update the list of boot devices in the NVRAM (nonvolatile random access memory). The NVRAM list can be modified by using the bootlist command.

Finally, the default of the mirrorvg command is for the quorum to be turned off. To turn quorum off on a rootvg volume group, the system must be rebooted.


Do not reboot the machine if the bosboot command has unsuccessfully created a boot disk. The problem should be resolved and the bosboot command run to successful completion. The bosboot command requires some space in the /tmp file system and the file system where the target image is to reside if there is such an image. Non-rootvg Mirroring

When this volume group is mirrored, the quorum gets deactivated. For the deactivation of the quorum to take effect, all open logical volumes must be closed. Then vary off and vary on the volume group for the changes to take effect.

If the re-vary on of the volume group is not performed, although the mirroring will work correctly, no quorum changes will have taken effect. Rootvg and Non-rootvg Mirroring

The system dump devices - primary(/dev/hd6) and secondary (/dev/sysdumpnull) - should not be mirrored. On some systems, the paging device and the dump device are the same device. However, most users want the paging device mirrored. When mirrorvg detects that a dump device and the paging device are the same, the logical volume will be mirrored automatically.

If mirrorvg detects that the dump and paging devices are different logical volumes, the paging device is automatically mirrored, but the dump logical volume is not. The dump device can be queried and modified with the sysdumpdev command.

6.3 Managing Physical Volumes