AIX: managing logical volumes with LVM

IBM AIX utilizes Logical Volume Manager (LVM) to abstract physical storage devices, providing flexible and resilient disk management. This article details…

IBM AIX utilizes Logical Volume Manager (LVM) to abstract physical storage devices, providing flexible and resilient disk management. This article details the essential commands and concepts for configuring, managing, and troubleshooting logical volumes (LVs) and volume groups (VGs) on AIX systems, focusing on common scenarios faced by system administrators.

Understanding LVM Components

AIX LVM operates with several key abstractions:

Physical Volumes (PVs): These are physical disk devices (e.g., hdisk0, hdisk1) or LUNs presented from a SAN. Before use, a PV must be initialized for LVM.
Physical Partitions (PPs): The smallest allocable unit on a PV. Their size is configurable per Volume Group. Common sizes are 4MB, 8MB, 16MB, 32MB, 64MB, 128MB, 256MB, 512MB, 1024MB. Larger PPs allow for larger LVs without exceeding LVM limits on the number of PPs.
Volume Groups (VGs): Collections of one or more PVs. VGs provide a pool of storage from which logical volumes are allocated. Each VG has a unique identifier (VGID).
Logical Volumes (LVs): Virtual disk partitions carved out of a VG. LVs are what file systems (JFS, JFS2) are created on, or they can be used as raw devices for databases. LVs can be mirrored across PVs within the same VG for data redundancy.

Creating Volume Groups and Logical Volumes

Initializing Physical Volumes and Creating a Volume Group

First, identify available physical disks. The lspv command lists all PVs, their VG assignments, and their state.

lspv

Output might look like:

hdisk0          00f9c2d1c6b12a0d    rootvg          active
hdisk1          none                None
hdisk2          00f9c2d1c6c1032e    oldvg           active

To use hdisk1 for a new volume group, ensure it's not assigned to any VG (None under VG column). Then, create the volume group. The mkvg command is used for this. The -y flag assigns a user-defined name, and -s specifies the physical partition size in MB. Choosing an appropriate PP size is crucial; for large disks or LVs, a larger PP size (e.g., 128MB) is recommended to avoid hitting the maximum 1016 PPs per LV limit in older AIX versions or 32K PPs in AIX 6.1+. For AIX 7.1 TL3+, PVs with capacities up to 2TB support a maximum of 128MB PP size, while PVs over 2TB support up to 1024MB PP size.

mkvg -y datavg -s 128 hdisk1

This creates a volume group named datavg with a 128MB physical partition size, using hdisk1 as its initial physical volume.

Creating Logical Volumes

Once the VG is established, LVs can be created within it. The mklv command creates a logical volume. The -y flag names the LV, -t specifies the type (e.g., jfs2 for JFS2 filesystems, raw for raw devices), and the last argument is the size. For filesystem LVs, it's best to specify the type as jfs2 from the start.

To create a 10GB JFS2 logical volume named datalv within datavg:

mklv -y datalv -t jfs2 datavg 10G

Alternatively, you can specify size in PPs. For a 10GB LV with 128MB PPs, this would be 10240MB / 128MB = 80 PPs:

mklv -y datalv -t jfs2 datavg 80

To create a mirrored logical volume with two copies (-c 2), where each copy resides on a separate PV if possible:

mklv -y mirroredlv -t jfs2 -c 2 datavg 20G

This command requires datavg to have at least two PVs to successfully mirror. If you don't specify the PVs explicitly, LVM attempts to place copies on different PVs. You can specify PVs using -u for upper-bound and -l for lower-bound inter-disk allocation policies, or directly with -p for specific PVs.

Creating Filesystems on Logical Volumes

After creating a jfs2 type logical volume, a JFS2 filesystem must be created on it using crfs. The -v jfs2 specifies the filesystem type, -d datalv is the LV name, -m /data is the mount point, and -A yes ensures it mounts automatically at system boot via /etc/filesystems.

crfs -v jfs2 -d datalv -m /data -A yes

Mount the filesystem:

mount /data

Verify with df -g or mount.

Extending and Reducing Logical Volumes and Volume Groups

Extending a Volume Group

To add more physical disks to an existing VG, use extendvg. This expands the storage pool available to the VG. For instance, to add hdisk2 to datavg:

extendvg datavg hdisk2

Extending a Logical Volume

The extendlv command expands an LV. If a filesystem resides on the LV, it must be online. AIX's JFS2 allows online filesystem resizing. For example, to extend datalv by 5GB:

extendlv datalv 5G

Then, resize the JFS2 filesystem to match the new LV size:

chfs -a size=+5G /data

Note: The chfs -a size=... command operates on the filesystem size, not the LV. When using +, it extends by the specified amount. Without +, it sets the absolute size. The LV must be large enough to accommodate the new filesystem size. For raw LVs, no filesystem resize is needed.

Reducing a Logical Volume and Filesystem (Cautionary)

Reducing LVs and filesystems is a higher-risk operation and requires careful planning and backups. It's often safer to migrate data, delete, and recreate smaller LVs.

1. Unmount the filesystem:

umount /data

2. Shrink the JFS2 filesystem. This command reduces the filesystem to its minimum possible size based on actual data, or to a specified target size. Back up data before attempting. Here, we shrink to 8GB. This example uses a specific size; for minimum size, omit the explicit size.

chfs -a size=8G /data

3. Reduce the logical volume using reducemlv or rmlvcopy (if mirrored). There is no direct reducelv for unmirrored LVs that dynamically shrinks the LV. For JFS2 filesystems, after shrinking with chfs, the underlying LV size is often automatically reduced to match the filesystem size. If not, manual reduction of an unmirrored LV is typically not supported without recreating the LV. For mirrored LVs, you can reduce copies, which may reduce the overall LV size if it was explicitly defined to span multiple PVs.

If you absolutely need to reduce an unmirrored LV, the safest method is often:

Backup all data from the filesystem.
Unmount the filesystem.
Remove the filesystem entry from /etc/filesystems (rmfs /data).
Remove the logical volume (rmlv datalv).
Create a new logical volume of the desired smaller size (mklv -y datalv -t jfs2 datavg 8G).
Create a new filesystem (crfs -v jfs2 -d datalv -m /data -A yes).
Restore data.

Managing LVM Mirroring

Adding Mirror Copies

To add a mirror copy to an existing logical volume, use mklvcopy. This requires the VG to have sufficient free PPs on a different PV than the original LV copy.

mklvcopy datalv 2 hdisk2

This creates a second copy of datalv on hdisk2. The 2 signifies the target number of copies (including the existing one). If hdisk2 is not specified, LVM will attempt to find a suitable PV.

Removing Mirror Copies

Use rmlvcopy to remove a mirror copy. This is often done to free up space on a PV or to replace a failing disk.

rmlvcopy datalv 1 hdisk2

This reduces datalv to a single copy, specifically removing the copy residing on hdisk2. Ensure you have a valid backup before reducing mirror copies.

Verifying Mirror Status

The lslv command shows the status of an LV, including mirroring. Look for the LV STATE and NUM COPIES fields.

lslv datalv

For more detailed PV-level mirroring status, use lsvg -l datavg to list all LVs in the VG, and lsvg -p datavg to list PVs and their usage.

Importing and Exporting Volume Groups

These operations are critical for migrating VGs between AIX systems or recovering VGs from failed systems.

Exporting a Volume Group

Exporting a VG makes it inactive on the current system and prepares it for import on another system. All LVs within the VG must be unmounted and closed (no open files/devices).

exportvg datavg

This removes datavg's definition from the ODM (Object Data Manager) and sets its state to inactive. The PVs are still marked with the VGID.

Importing a Volume Group

On the target system, the PVs that constitute the exported VG must be visible (e.g., SAN LUNs). Use importvg to bring the VG online. The -y flag provides a new name (or keeps the original). The hdisk name is one of the PVs in the VG.

importvg -y datavg hdisk1

If there's a VGID conflict with an existing VG, you may need to use -V <new_vgid>, but this is rare in clean export/import scenarios.

Common Pitfalls and Troubleshooting

"0516-008 lvm command failed" errors: These are generic LVM errors. Always check the system error log (errpt -a | pg) for more specific LVM-related messages.
PV not available for VG creation/extension: Ensure the disk is not already part of another VG (lspv) and is recognized by AIX (lscfg -vl hdiskX). For SAN LUNs, verify zoning and masking.
Running out of PPs in a VG or LV: If a VG or LV has a small PP size and many physical partitions, you might hit LVM limits (e.g., 32768 PPs per VG in AIX 7.1+). Plan your PP size carefully during VG creation. There's no direct command to change PP size for an existing VG.
Filesystem resize failures: Always ensure the underlying LV has enough free space before attempting to extend the filesystem. For reduction, unmount and back up data first. Check lsfs and lslv <lvname> for current sizes.
Mirror synchronization issues: If a disk in a mirrored VG fails, LVM might report "STALE" PPs. Replace the failed disk, then use syncvg -v <vgname> to resynchronize. You can monitor progress with lsvg -l <vgname>.
VG activation failure on boot: Check /etc/inittab for LVM-related entries (e.g., lvmo or synclv) and ensure they are correct. Use varyonvg <vgname> manually to attempt activation.