HP -UX 11i Version 3 Logical Volume Manager System Administrator's Guide
Reklamë
Reklamë
HP-UX System Administrator's Guide: Logical
Volume Management
HP-UX 11i Version 3
Abstract
This document describes how to configure, administer, and troubleshoot the Logical Volume Manager (LVM) product on the
HP-UX Version 3 platform.
The HP-UX System Administrator’s Guide is written for administrators of HP-UX systems of all skill levels needing to administer
HP-UX systems beginning with HP-UX Release 11i Version 3.
While many topics in this set apply to previous releases, much has changed in HP-UX 11i Version 3. Therefore, for information about prior releases, see Managing Systems and Workgroups: A Guide for System Administrators.
HP Part Number: B3921-90053
Published: September 2011
Edition: 8
© Copyright 2011 Hewlett-Packard Development Company, L.P.
Legal Notices
Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial
Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. UNIX is a registered trademark of The Open Group.
Trademark Notices
VERITAS™ is a registered trademark of Symantec Corporation.
Contents
1 Introduction...............................................................................................8
2 Configuring LVM......................................................................................20
Contents 3
3 Administering LVM....................................................................................38
4 Contents
4 Troubleshooting LVM...............................................................................107
Contents 5
5 Support and Other Resources...................................................................141
A LVM Specifications and Limitations............................................................147
B LVM Command Summary........................................................................152
C Volume Group Provisioning Tips...............................................................155
6 Contents
D Striped and Mirrored Logical Volumes.......................................................157
E LVM I/O Timeout Parameters....................................................................161
F Warning and Error Messages...................................................................163
Glossary..................................................................................................177
Index.......................................................................................................179
Contents 7
1 Introduction
This chapter addresses the following topics:
•
•
•
“Physical versus Logical Extents” (page 10)
•
“LVM Volume Group Versions” (page 11)
•
“LVM Device File Usage” (page 12)
•
•
•
LVM Features
Logical Volume Manager (LVM) is a storage management system that lets you allocate and manage disk space for file systems or raw data. Historically, you treated your disks individually and in terms of fixed-sized partitions; each disk or partition held a file system, swap space, boot area, or raw data. With LVM, you do not need to assign a disk or fixed-sized partition to a single purpose. Instead, consider the disks as a pool (or volume) of data storage, consisting of equal-sized extents. Extents are allocated into virtual storage devices known as
logical volumes , which can be
treated as disks.
LVM provides the following capabilities:
•
A logical volume size can be dynamically reduced or expanded to meet changing data needs.
For example, a logical volume can be as small or large as the file system mounted to it requires.
The file system can be extended without rebuilding it or the logical volume; reducing a file system is more complex, and may require recreating the file system.
•
Small chunks of unused space from several disks can be combined to create a usable volume.
•
A logical volume can exceed the size of a single physical disk. This feature is called
, because a single file system (and individual files) can span disks.
•
Up to six copies of identical data can be stored and updated simultaneously using LVM. This feature is called
a logical volume, and requires an optional product, HP
MirrorDisk/UX. See
“Increasing Data Availability Through Mirroring” (page 24)
.
•
Mirrored data can be configured to automatically create a new mirror to a separate disk when one of the mirror copies fails. This feature is called sparing, and requires an optional product, HP MirrorDisk/UX. See
“Increasing Disk Redundancy Through Disk Sparing”
.
•
A logical volume can be created so that logically contiguous data blocks (for example, chunks of the same file) are distributed across multiple disks, which speeds I/O throughput for large files when they are read and written sequentially. This feature is called striping. Striping can be used in conjunction with mirroring. See
“Increasing Performance Through Disk Striping”
.
•
A point-in-time image of a logical volume can be created, called a snapshot logical volume.
See
“Creating and Administering Snapshot Logical Volumes” (page 103)
.
•
Devices accessed through multiple links can be configured to improve availability. If the primary link to a device fails, LVM can switch automatically to an alternate link. This feature is called multipathing. See
“Increasing Hardware Path Redundancy Through Multipathing” (page 28)
.
8 Introduction
LVM Architecture
An LVM system starts by initializing disks for LVM usage. An LVM disk is known as a
(PV). A disk is marked as an LVM physical volume using either the HP System Management
Homepage (HP SMH) or the pvcreate command. Physical volumes use the same device special files as traditional HP-UX disk devices.
LVM divides each physical volume into addressable units called
(PEs). Starting after the LVM metadata at the beginning of the disk, extents are allocated sequentially, with an index starting at zero and incrementing by one for each unit. The physical extent size is configurable at the time you form a volume group and applies to all disks in the volume group. You can select a size from 1 MB to 256 MB.
Physical volumes are organized into
(VGs). A volume group can consist of one or more physical volumes, and there can be more than one volume group in the system. Once created, the volume group, not the disk, is the entity that represents data storage. Thus, whereas earlier you moved disks from one system to another, with LVM, you move a volume group from one system to another. Therefore, it is often convenient to have multiple volume groups on a system.
The pool of disk space that is represented by a volume group can be divided into
(LVs) of various sizes. Once created, logical volumes can be treated just like disk partitions. They are accessible through device special files. A logical volume can span a number of physical volumes in a volume group or represent only part of one physical volume.
The basic allocation units for a logical volume are called
(LEs). A logical extent is mapped to a physical extent. Thus, if the physical extent size is 4 MB, the logical extent size is also 4 MB. The size of a logical volume is determined by the number of logical extents configured.
Starting with volume group Version 2.2, LVM introduced a new type of logical volume:
create another copy of the logical volume (which can be used for a backup) without taking up as much of the physical space as the size of the logical volume. See
Snapshot Logical Volumes” (page 103)
for more information about snapshots.
You assign file systems, swap, dump, or raw data to logical volumes. For example, in
, logical volume /dev/vg01/lvol1 might contain a file system, logical volume /dev/vg01/ lvol2 might contain swap space, and logical volume /dev/vg01/lvol3 might contain raw data. You can use HP SMH to create a file system in a logical volume of a specified size, then mount the file system. Alternately, you can use LVM commands to create, then extend a logical volume to allocate sufficient space for file systems or raw data. You then create and mount new file systems or install your application in the logical volume.
LVM Architecture 9
Figure 1 Disk Space Partitioned Into Logical Volumes
Physical versus Logical Extents
When LVM allocates disk space to a logical volume, it automatically creates a mapping of the logical extents to physical extents. This mapping depends on the policy chosen when creating the logical volume. Logical extents are allocated sequentially, starting at zero, for each logical volume.
LVM uses this mapping to access the data, regardless of where it physically resides. Commands are provided for you to examine this mapping; see pvdisplay(1M) and lvdisplay(1M).
Except for mirrored, striped, or striped-mirrored logical volumes, each logical extent is mapped to one physical extent. For mirrored logical volumes, each logical extent is mapped to multiple physical extents, depending on the number of mirror copies. For example, if one mirror copy exists, then each logical extent maps to two physical extents, one extent for the original and one for the mirror copy. For more information on mirroring, see
“Increasing Data Availability Through Mirroring”
. For information on striped logical volumes, see
“Increasing Performance Through Disk
. Also refer to the book Disk and File Management Tasks on HP-UX.
shows an example of several types of mapping available between physical extents and logical extents within a volume group.
10 Introduction
Figure 2 Physical Extents and Logical Extents
As shown in
, the contents of the first logical volume are contained on all three physical volumes in the volume group. Because the second logical volume is mirrored, each logical extent is mapped to more than one physical extent. In this case, there are two physical extents containing the data, each on both the second and third disks within the volume group.
By default, LVM assigns physical extents to logical volumes by selecting available physical extents from disks in the order in which they appear in the LVM configuration files, /etc/lvmtab and
/etc/lvmtab_p
. As a system administrator, you can bypass this default assignment and control which disks are used by a logical volume (see
“Extending a Logical Volume to a Specific Disk”
).
If a logical volume is to be used for root, boot, primary swap, or dump, the physical extents must be contiguous, which means that the physical extents must be allocated in increasing order with no gaps on a single physical volume. For logical volumes that are not being used for root, boot, primary swap or dump, physical extents that correspond to contiguous logical extents within a logical volume can be noncontiguous on a physical volume or reside on entirely different disks.
As a result, a file system created within one logical volume can reside on more than one disk.
LVM Volume Group Versions
As of the March 2010 release of HP-UX 11i Version 3, LVM supports four versions of volume groups. All information and tasks in this document apply to all volume group versions except where noted.
Version 1.0 is the version supported on all current and previous versions of HP-UX 11i. The procedures and command syntax for managing Version 1.0 volume groups are unchanged from previous releases. When creating a new volume group, vgcreate defaults to Version 1.0.
LVM Volume Group Versions 11
Version 2.0, 2.1, and 2.2 enable the configuration of larger volume groups, logical volumes, physical volumes, and other parameters. Version 2.1 is identical to Version 2.0, but allows a greater number of volume groups, physical volumes, and logical volumes. Version 2.x volume groups are managed exactly like Version 1.0 volume groups, with the following exceptions:
•
Version 2.x volume groups have simpler options to the vgcreate command. When creating a Version 2.x volume group, you specify only the extent size and the maximum size to which the volume group can grow. This gives LVM greater flexibility in managing space; you can use the same parameters for a volume group with many small PVs and for a volume group with a few large PVs. For more information on volume group creation, see
•
Version 2.0 volume groups are not recognized on previous releases of HP-UX, including versions of HP-UX 11i Version 3 before March 2008. Version 2.1 volume groups are not recognized on previous releases of HP-UX, including versions of HP-UX 11i Version 3 before
September 2008. Version 2.2 volume groups are only supported on systems operating with the HP-UX 11i Version 3 March 2010 Update and forward.
•
Version 2.0 and 2.1 volume groups do not support root, boot, swap, or dump logical volumes.
The lvlnboot and lvrmboot commands display an error message if run on a Version 2.0
or 2.1 volume group. Note that Version 2.2 and higher do support root, boot, swap, or dump logical volumes.
•
Version 2.0 and 2.1 volume groups do not support bootable physical volumes. You cannot add a physical volume created with pvcreate -B to a Version 2.0 or 2.1 volume group.
Note that Version 2.2 and higher do support bootable physical volumes.
•
Version 2.2 or higher volume groups support creation of snapshots of logical volumes.
•
Version 2.x volume groups do not support disk sparing. Using the -z option to the vgextend or pvchange command displays an error message.
•
The pvck command is not supported on Version 2.x volume groups.
•
Some HP-UX products do not support Version 2.x volume groups. For more information, see the HP-UX Logical Volume Manager and MirrorDisk/UX Release Notes for your release.
To compare Version 1.0 and Version 2.x volume groups, see the tables that list maximum limits for different volume group versions in
“LVM Specifications and Limitations” (page 147)
. You can also display volume group limits with the lvmadm command; an example is shown in
Specifications and Limitations” (page 147)
. The lvmadm is fully covered in the lvmadm(1M) manual page.
See
“Creating and Administering Snapshot Logical Volumes” (page 103)
for information about snapshot logical volumes.
LVM Device File Usage
All LVM components are represented by device special files located in the /dev directory. Device special files act as agents for managing the interactions with the disk space. The LVM device files are created by both HP SMH and HP-UX commands. This section describes the device special files used by LVM, and naming conventions for LVM objects.
HP-UX 11i v3 introduces a new representation of mass storage devices called the agile view. In this representation, the device special file (DSF) name for each disk no longer contains path (or link) information. The multipathed disk has a single persistent DSF regardless of the number of physical paths to it. The legacy view, represented by the legacy DSF, continue to exist.
Legacy Device Files versus Persistent Device Files
As of HP-UX 11i Version 3, disk devices can be represented by two different types of device files in the /dev directory, legacy and persistent.
12 Introduction
Legacy device files were the only type of mass storage device files in releases prior to HP-UX 11i
Version 3. They have hardware path information such as SCSI bus, target, and LUN encoded in the device file name and minor number. For example, the legacy device file /dev/dsk/c3t2d0 represents the disk at card instance 3, target address 2, and lun address 0.
Persistent device files are not tied to the physical hardware path to a disk, but instead map to the disk's unique worldwide identifier (WWID). Thus, the device file is unchanged if the disk is moved from one interface to another, moved from one switch or hub port to another, or presented from a different target port to the host. The name of a persistent device file follows a simpler naming convention: /dev/disk/diskn, where n is the instance number assigned to the disk. Neither the device file name nor the minor number contain any hardware path information.
In addition, if the disk has multiple hardware paths, it is represented by a single persistent device file. Persistent device files transparently handle multipathed disks and supersede LVM's multipathing functionality described in
“Increasing Hardware Path Redundancy Through Multipathing” (page 28)
.
If a disk has multiple hardware paths, which LVM refers to as pvlinks, the persistent device special file acts as a single access point for all the links. I/O requests are distributed across all available links by the mass storage stack, with a choice of load balancing algorithms. If a link fails, the mass storage stack automatically disables the failed link and I/O continues on all remaining links. Any failed or nonresponsive links are monitored, so that when a failed link recovers, it is automatically and transparently reincorporated into any load balancing. New disks and links are also automatically discovered and added to load balancing. If the disk's connectivity changes—addition, removal, or modification of a link—applications using the persistent device file are not affected, provided at least one link is still active. New disks are automatically discovered.
You can use either persistent or legacy device files for LVM disks. LVM recommends the use of persistent device special files, because they support a greater variety of load balancing options.
To facilitate migration from legacy DSF to persistent DSF, HP provides the
/usr/contrib/bin/vgdsf script, which works for both root and non-root volume groups. For more detail on the HP-UX 11i v3 mass storage stack, its new features (such as the persistent DSFs), and their benefits, see The Next Generation Mass Storage, HP-UX 11i v3 White Paper on http:// www.hp.com/go/hpux-core-docs.
NOTE: To use LVM's alternate link functionality, you must use legacy device files, and disable multipathing through those legacy device files, as described in
Redundancy Through Multipathing” (page 28)
.
Cluster-wide Device Special Files
HP-UX 11i Version 3, September 2010 Release introduces the support of cluster-wide device special files (cDSF) for nodes running with Serviceguard, A.11.20.
A cluster device special files provides a consistent set of device special files across a set of cluster nodes. The cluster device special files of a LUN will be the same on any node in a specified set of nodes that share the LUN. The set of cluster nodes across which cluster device special files need to be created can be specified using the cmsetdsfgroup command. The cluster device special files can be displayed using the io_cdsf_config command. See the Managing Serviceguard
Eighteenth Edition manual for more detail on cluster device special files
Naming Conventions for LVM
You must refer to LVM devices or volume groups by name when using them within HP SMH or with
HP-UX commands. By default, the LVM device files created by both HP SMH and HP-UX commands follow a standard naming convention. However, you can choose customized names for volume groups and logical volumes.
Physical Volume Names
Physical volumes are identified by their device file names, as follows:
LVM Device File Usage 13
Table 1 Physical Volume Naming Conventions
Device File Name
/dev/disk/diskn
/dev/disk/diskn_p2
/dev/rdisk/diskn
/dev/rdisk/diskn_p2
/dev/dsk/cntndn
/dev/dsk/cntndns2
/dev/rdsk/cntndn
/dev/rdsk/cntndns2
/dev/cdisk/diskn
/dev/rcdisk/diskn
Type of Device
Persistent block device file
Persistent block device file, partition 2
Persistent character device file
Persistent character device file, partition 2
Legacy block device file
Legacy block device file, partition 2
Legacy character device file
Legacy character device file, partition 2
Cluster block device file
Cluster character device file
Each disk has a block device file and a character or raw device file, the latter identified by the r.
Which name you use depends on what task you are doing with the disk.
For the boot disk on HP Integrity servers, make sure to use the device files with the _p2 suffix or s2 suffix, because they represent the HP-UX partition on the boot disk. On HP 9000 servers, use the device file without a partition number.
Use a physical volume’s raw device file for the following tasks only:
•
Preparing a physical volume for LVM using the pvcreate command. Here you use the device file for the disk; for example, /dev/rdisk/disk14. (The absence of a partition suffix indicates that you are referring to the entire disk.)
•
Removing LVM information from a physical volume using the pvremove command.
•
Restoring your volume group configuration using the vgcfgrestore command.
•
Performing a consistency check on a physical volume using the pvck command.
•
Modifying the volume group identifier on a physical volume using the vgchgid command.
•
Changing the disk type of a physical volume using the vgmodify command.
For all other tasks, use the block device file. For example, when you add a physical volume to a volume group using the vgextend command, you use the disk’s block device file for the disk, such as /dev/disk/disk14.
All disk device files are created automatically when a new disk is discovered. For more information, see insf(1M).
Volume Group Names
Each volume group must have a unique name, up to 255 characters. For example, typical volume group names are vg01, vgroot, or vg_sales. Although the name does not need to start with vg
, HP recommends using this prefix. By default, HP SMH uses the names of the form /dev/vgnn.
The number nn starts at 00 and is incremented in the order that volume groups are created. By default, the root volume group is vg00.
Logical Volume Names
Logical volumes are identified by their device file names, which can either be assigned by you or assigned by default when you create a logical volume using the lvcreate command.
When assigned by you, you can choose any name up to 255 characters.
14 Introduction
When assigned by default, these names take the form /dev/vgnn/lvolN (the block device file form) and /dev/vgnn/rlvolN (the character device file form). The number N starts at 1 and increments in the order that logical volumes are created within each volume group.
When LVM creates a logical volume, it creates both block and character device files. LVM then places the device files for a logical volume in the appropriate volume group directory. For example, the default block name for the first logical volume created in volume group vg01 has the following full path name:
/dev/vg01/lvol1
If you create a logical volume to contain a sales database, you can name it explicitly as follows:
/dev/vg01/sales_db_lv
After the logical volume in the previous example is created, it has two device files: /dev/vg01/ sales_db_lv for the block device file and /dev/vg01/rsales_db_lv for the character, or raw, device file.
Physical Volume Group Names
Physical volume groups are useful for mirroring and are discussed in
Through I/O Channel Separation” (page 33) . The only naming restriction is that within a volume
group, each physical volume group must have its own unique name. For example, the volume group /dev/vg02 might have two physical volume groups named pvg1 and pvg2.
Snapshot Logical Volume Names
The lvcreate command is used to create a snapshot logical volume, and its -n option can specify the name of the snapshot logical volume. If this option is not used, then the snapshot logical volume name defaults to the string comprising of the original logical volume name, the tag S, and the snapshot volume minor number N, where N is the decimal equivalent of the least significant 12 bits of the snapshot volume's minor number. The range for N is 1 to 2047.
Additionally, you can use the lvcreate -t option to append the timestamp to the snapshot volume name. The timestamp is of the form: YYYYMMDD_HH.MM.SS. The default is to not append a timestamp to the name of the snapshot. The lvcreate(1M) manpage provides full details on creating snapshot logical volumes. See
“Creating and Administering Snapshot Logical Volumes”
for more information about snapshot logical volumes.
Device Number Format
The device files associated with LVM reside in the /dev directory. For each volume group, a directory under /dev is named after the volume group. In that directory is a single “group” device file and separate block and character device files for each logical volume.
The following is a sample listing:
# ls -l /dev/vg01 total 0 crw-r--r-- 1 root root 64 0x010000 Mar 28 2004 group brw-r----- 1 root root 64 0x010001 Jul 29 16:53 lvol1 brw-r----- 1 root root 64 0x010002 Jul 29 16:53 lvol2 crw-r----- 1 root root 64 0x010001 Mar 28 2004 rlvol1 crw-r----- 1 root root 64 0x010002 Mar 28 2004 rlvol2
By default, volume group numbering begins with zero (vg00), while logical volumes begin with one (lvol1). This is because the logical volume number corresponds to the minor number and the volume group's group file is assigned minor number 0.
Physical volumes use the device files associated with their disk. LVM does not create device files for physical volumes.
LVM Device File Usage 15
Version 1.0 Device Number Format
lists the format of the device file number for Version 1.0 volume groups.
Table 2 Version 1.0 Device Number Format
Major Number Reserved
64
Volume Group
Number
0–0xff 0
Logical Volume
Number
0–0xff
0=group file
For Version 1.0 volume groups, the major number for LVM device files is 64. The volume group number is encoded into the top eight bits of the minor number, and the logical volume number is encoded into the low eight bits. Logical volume number 0 is reserved for the group file.
Version 2.x Device Number Format
lists the format of the device file number for Version 2.x volume groups.
Table 3 Version 2.x Device Number Format
Major Number
128
Volume Group Number
0–0x7ff
Logical Volume Number
0–0x7ff
0=group file
For Version 2.x volume groups, the major number for LVM device files is 128. The volume group number is encoded into the top twelve bits of the minor number, and the logical volume number is encoded into the low twelve bits. Logical volume number 0 is reserved for the group file.
NOTE: The most significant bit of the volume group number and logical volume number fields are reserved and must be zero.
The device number format is subject to change.
LVM Disk Layout
NOTE: This information applies only to disks belonging to Version 1.0 and Version 2.2 (or higher) volume groups.
There are two kinds of LVM disk layouts, one for boot disks and another for all other LVM disks.
These differ in their data structures. Nonbootable disks have two reserved areas: the physical volume reserved area (PVRA) and the volume group reserved area (VGRA). Bootable disks have a PVRA and VGRA, and additional sectors reserved for the boot data reserved area (BDRA) and boot LIF.
Boot Data Reserved Area
The BDRA contains the information needed to configure the root, primary swap, and dump logical volumes, and to mount the root file system.
Information about the LVM disk data structures in the BDRA is maintained with the lvlnboot and lvrmboot commands. The following is a sample output:
# lvlnboot -v
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c3t0d0 -- Boot Disk
/dev/dsk/c4t0d0 -- Boot Disk
/dev/dsk/c5t0d0
/dev/dsk/c12t0d0 -- Boot Disk
Root: lvol1 on: /dev/dsk/c3t0d0
16 Introduction
/dev/dsk/c4t0d0
Swap: lvol2 on: /dev/dsk/c3t0d0
/dev/dsk/c4t0d0
Dump: lvol2 on: /dev/dsk/c3t0d0
The physical volumes designated "Boot Disk" are bootable, having been initialized with mkboot and pvcreate -B. Multiple lines for lvol1 and lvol2 indicate that the root and swap logical volumes are being mirrored.
Logical Interface Format Area
LVM boot disks contain a Logical Interface Format (LIF) area, in which is stored a LABEL file. On
HP 9000 servers, the LIF area contains boot utilities such as the initial system loader (ISL), the kernel boot loader (HPUX), the autoboot file (AUTO), and offline diagnostics.
The LABEL file is created and maintained by lvlnboot and lvrmboot. It contains information about the starting point and size of boot-relevant logical volumes, including the boot file system
(/stand). Utilities can use the LABEL file to access the root, primary swap, and dump logical volumes without actually using LVM.
Physical Volume Reserved Area
The physical volume reserved area (PVRA) contains information describing the physical volume, such as its unique identifier, physical extent information, and pointers to other LVM structures on the disk.
Volume Group Reserved Area
The volume group reserved area (VGRA) describes the volume group to which the disk belongs.
The information is replicated on all of the physical volumes and updated whenever a configuration change is made. Among other data, it contains the following information:
•
A list of physical volumes in the volume group, including physical volume status and size, and a map of physical extents to logical volumes.
•
A list of logical volumes in the volume group (including the status and capabilities of each logical volume), its scheduling and allocation policies, and the number of mirror copies.
•
A volume group header containing the VGID and three configurable parameters:
◦ the number of physical volumes allowed in the volume group
◦ the maximum number of logical volumes allowed in the volume group
◦ the maximum number of physical extents allowed per physical volume
Since each physical extent is recorded in the VGRA, the extent size has a direct bearing on the size of the VGRA. In most cases, the default extent size is sufficient. However, if you encounter problems, consider that the VGRA is a fixed size and a high-capacity physical volume might exceed the total number of physical extents allowed. As a result, you might need to use a larger-than-default extent size on high-capacity LVM disks. Conversely, if all LVM disks in a volume group are small, the default number of extents might make the VGRA too large, wasting disk and memory space.
A smaller-than-default extent size or number of physical extents might be preferable. A high-capacity physical volume might be unusable in a volume group whose extent size is small or set with a small number of physical extents per disk.
User Data Area
The user data area is the region of the LVM disk used to store all user data, including file systems, virtual memory system (swap), or user applications.
LVM Disk Layout 17
LVM Limitations
LVM is a sophisticated subsystem. It requires time to learn, it requires maintenance, and in rare cases, things can go wrong.
HP recommends using logical volumes as the preferred method for managing disks. Use LVM on file and application servers. On servers that have only a single disk and are used only to store the operating system and for swap, a “whole-disk” approach is simpler and easier to manage. LVM is not necessary on such systems.
By default, LVM configurations are automatically backed up each time you change them, in the default directory, /etc/lvmconf. Mirroring provides insurance against data loss that is not available under the whole-disk method.
NOTE: This default directory /etc/lvmconf can be changed for volume groups Version 2.x
by configuring a new path in the LVMP_CONF_PATH_NON_BOOT variable defined in the /etc/ lvmrc file. See vgcfgbackup(1M) for details.
Additional limitations to LVM include the following:
•
Both LVM disks and non-LVM disks can exist simultaneously on your system, but a given disk or partition must be managed entirely by either LVM or non-LVM methods. That is, you cannot combine these techniques for use with a single disk or partition.
•
On an HP Integrity server, LVM supports partitioning of the root disk and its mirrors only, and supports only one HP-UX partition on any disk.
•
Floppy disks, optical disks, and CD-ROMs do not support logical volumes.
•
You must use an LVM or VERITAS™ Volume Manager (VxVM) disk for your root disk.
•
To use LVM, a disk must be first initialized into a physical volume.
•
To be allocatable for storage, a physical volume must be assigned to a volume group.
•
A physical volume can belong to only one volume group.
•
The extent size of a volume group is fixed when the volume group is created. It cannot be changed without recreating the volume group.
Shared LVM
Shared LVM (SLVM) allows multiple systems in a Serviceguard cluster to share (read/write) disk resources in the form of volume groups. SLVM is designed to be used by specialized distributed applications that use raw access to disks, rather than going through a file system.
Shared mode is configured with the vgchange command. The vgdisplay command will show the current activation mode for the volume group.
The following commands have restrictions when operated on volume groups that are activated in shared mode:
•
For volume group Version 1.0 or 2.0, lvchange, lvcreate, lvextend, lvmerge, lvmove, lvreduce
, lvremove, lvsplit, vgextend, vgmodify, vgmove, and vgreduce cannot be used in shared mode.
•
The pvmove command cannot be used in shared mode for volume group Version 1.0.
•
For pvchange, only the -a option (for attaching or detaching a path to the specified physical volume) is allowed in shared mode. All other pvchange options are not supported in shared mode.
To replace disks that are part of a volume group shared by a Serviceguard cluster, the physical volume must be detached and attached (using pvchange) independently on each of the systems in the cluster.
•
The lvlnboot and lvrmbootcommands cannot be used in shared mode.
18 Introduction
Volume group Version 2.2 and higher with snapshot logical volumes configured cannot be activated in shared mode. Also, snapshots cannot be created off logical volumes belonging to shared volume groups.
Synchronization of mirrored volume groups will be slower on shared volume groups.
Beginning with the September 2009 Update, LVM provides new options in LVM commands to let system administrators reconfigure shared volume groups, logical volumes, and physical volumes on multiple nodes in a cluster, while user applications and data reads/writes remain available and active. lvmpud is the daemon that handles LVM online shared volume group reconfiguration.
The online reconfiguration of shared volume groups is only available on volume groups version
2.1 and higher. See the SLVM Online Reconfiguration white paper for details.
For Version 1.0 and 2.0 volume groups, you can use the vgchange -x option (the SLVM SNOR feature) to change the configuration of a shared volume group, while keeping it active only on a single node. Using this procedure, applications on at least one node remain available during the volume group reconfiguration.
The shared LVM features, options, and restrictions are fully covered in the LVM command manpages.
See
“LVM Command Summary” (page 152)
for supported LVM commands. Each LVM command has a manpage that is installed with the LVM product.
Shared LVM 19
2 Configuring LVM
By default, the LVM commands are already installed on your system. This chapter discusses issues to consider when setting up your logical volumes. It addresses the following topics:
•
“Planning Your LVM Configuration” (page 20)
•
“Setting Up Different Types of Logical Volumes” (page 20)
•
“Planning for Availability” (page 24)
•
“Planning for Recovery” (page 34)
•
“Planning for Performance” (page 29)
Planning Your LVM Configuration
Using logical volumes requires some planning. Some of the issues to consider for planning purposes are discussed in this chapter. Consider these issues before setting up or modifying logical volumes on your system.
•
For what purpose will you use a logical volume? For raw data or a file system? As a swap area or dump area? See
“Setting Up Different Types of Logical Volumes” (page 20)
.
•
How big will you make a logical volume?
•
Does your data require high availability? If so, consider mirroring your logical volume across multiple disks, as described in
“Increasing Data Availability Through Mirroring” (page 24) .
Also consider setting up spare disks to handle mirror failure, as described in
Redundancy Through Disk Sparing” (page 27)
.
•
Is I/O performance very important to you? If so, consider striping your logical volumes across multiple disks, as described in
“Increasing Performance Through Disk Striping” (page 31) ,
and separating I/O channels, as described in
“Increasing Performance Through I/O Channel
. For additional recommendations for performance, read
.
•
Do you need to balance high availability and I/O performance? If so, consider striping and mirroring your logical volume, as described in
“Increasing Data Availability Through Mirroring”
and
“Increasing Performance Through Disk Striping” (page 31) .
•
Is it important to recover from disk failures quickly? If so, see
“Planning for Recovery” (page 34)
.
Setting Up Different Types of Logical Volumes
This section contains information on setting up special logical volumes.
Setting Up Logical Volumes for Raw Data Storage
You can optimize raw I/O performance by planning your logical volumes specifically for raw data storage. To create a raw data logical volume (such as for a database), consider how large the logical volume must be and how such a logical volume is distributed over your disks.
Typically, you specify the size of a logical volume in megabytes. However, a logical volume must be a multiple of the extent size used in the volume group. For example, if a database partition requires 2002 MB and the logical extent size is 4 MB, LVM creates a logical volume that is 2004
MB (or 501 logical extents).
If you plan to use logical volumes heavily for raw data storage (such as for setting up database partitions), consider how the logical volumes are distributed over your disks.
By default, LVM assigns disk space for a logical volume from one physical volume, uses the space on this physical volume entirely, then assigns space from each successive physical volume in the same manner. LVM uses the physical volumes in the order in which they appear in /etc/lvmtab
20 Configuring LVM
and /etc/lvmtab_p, which means that data of a logical volume might not be evenly distributed over all the physical volumes within your volume group.
As a result, when I/O access to the logical volumes occurs, one or more disks within the volume group might be heavily used, while the others might be lightly used, or not used at all. This arrangement does not provide optimum I/O performance.
As a better alternative, you can set up your logical volume on specific disks in an interleaved manner, thus balancing the I/O access and optimizing performance (see
Because there are no HP-UX commands that identify that the contents of a logical volume are being used for raw data, use recognizable names for the logical volumes you create for raw data. In this way, you can recognize the contents of such a logical volume.
Setting Up Logical Volumes for File Systems
File systems reside in a logical volume just as they do within disk partitions or nonpartitioned disks.
Two types of file systems can be used in a logical volume: Hierarchical File Systems (HFS) and
Journaled File Systems (JFS) (VxFS).
Choosing the Initial Size of File System Logical Volumes
When determining the required space for a file system, consider the three major components shown in
.
Figure 3 File System Space Components
To estimate how big to make a logical volume that will contain your file system, follow these steps:
1.
Estimate how much disk space users will need for their data in the future. Allow for any anticipated changes, which usually include additional growth. (Use the du command to see how much disk space is currently used.)
2.
Add 10% to the above amount for a “minfree” area; this area is reserved to maintain performance.
3.
Add another 5% for file system overhead; this includes all data structures required to maintain the file system.
4.
Round up to the next integer multiple of the logical extent size used in this logical volume to find the size in logical extents. (This step is performed automatically when you create a logical volume.)
For example, if a group of users will require 60 MB space for file system data, the following estimate allows for expected growth. Add 6 MB for the minfree space. Then add 3 MB for file system overhead for a total estimate of 69 MB required by the file system, and for the logical volume that contains the file system. If you are creating the logical volume in a volume group that has an extent size of 4 MB, round 69 to 72 to make it divisible by 4 MB.
Although these estimates are not precise, they suffice for planning a file system size. Create your file system large enough to be useful for some time before increasing its size.
Setting Up Different Types of Logical Volumes 21
TIP: Because increasing the size of a file system is usually easier than reducing its size, be conservative in estimating how large to create a file system.
An exception is the root file system. As a contiguous logical volume, the root file system is difficult to extend.
Resizing File System Logical Volumes
If your users have outgrown the space originally allocated for the file system, you can increase its size by first enlarging the logical volume it resides in using the lvextend command, then using the extendfs command to enlarge the file system contained in the logical volume.
Decreasing the size of a file system can be difficult. Based on the type of file system, you might not be able to decrease its size. However, you can create a new smaller file system to take its place.
For more information on resizing file system logical volumes, see
“Administering File System Logical
.
File System Logical Volume Guidelines
Use the following guidelines when configuring file system logical volumes:
•
If you create a file system that spans LVM disks, be sure that the logical volume in which the file system resides spans identical disk types for best system performance.
•
By default, LVM creates logical volumes on available disks, not necessarily with regard for best performance. A file system can span two disks with different characteristics, in which case the file system performance can possibly be impaired.
You can control which physical volumes contain the physical extents of a logical volume by following these steps:
1.
Create a logical volume without specifying a size using the lvcreate command or HP
SMH. When you do not specify a size, by default, no physical extents are allocated for the logical volume.
2.
Extend the logical volume (that is, allocate space) to the specific physical volumes you want to contain the file system using the lvextend command.
•
The root or boot logical volume is limited to either 2 GB or 4 GB, depending on your processor.
Setting Up Logical Volumes for Swap
NOTE: Version 2.0 and 2.1 volume groups do not support swap logical volumes.
This section explains what to consider when using logical volumes as swap devices. For information on managing your system swap space, including determining how much and what type of swap space the system needs, see HP-UX System Administrator's Guide: Configuration Management.
When configured as swap, logical volumes are treated as device swap space. Device swap space occupies a logical volume or partition, which is typically reserved expressly for swapping purposes.
This space can also be configured as a dump area (See
“Dump Logical Volume Guidelines”
).
Swap Logical Volume Guidelines
Use the following guidelines when configuring swap logical volumes:
•
Interleave device swap areas for better performance.
Two swap areas on different disks perform better than one swap area with the equivalent amount of space. This configuration allows interleaved swapping, which means the swap areas are written to concurrently, thus enhancing performance.
22 Configuring LVM
When using LVM, set up secondary swap areas within logical volumes that are on different disks using lvextend.
If you have only one disk and must increase swap space, try to move the primary swap area to a larger region.
•
Similar-sized device swap areas work best.
Device swap areas must have similar sizes for best performance. Otherwise, when all space in the smaller device swap area is used, only the larger swap area is available, making interleaving impossible.
•
By default, primary swap is located on the same disk as the root file system. By default, the
/stand/system system kernel configuration file contains the configuration information for primary swap.
•
If you are using logical volumes as secondary swap, allocate the secondary swap to reside on a disk other than the root disk for better performance.
Setting Up Logical Volumes for Dump
NOTE: Version 2.0 and 2.1 volume groups do not support dump logical volumes.
This section explains what to consider when using logical volumes as dump devices. A dump area is disk space used to write an image of the core memory after a system crash. The analysis of a core dump can be useful in troubleshooting and restoring the system to working order.
By default, the primary swap device also serves as a dump area when no dump area is specifically designated. Although you are not required to retain primary swap as your dump area, doing so conserves disk space. You can configure a different or multiple dump devices on your system. To do this, create a logical volume as a dump device. This device can also be used for swap.
For information on adding, removing, or modifying dump devices, and configuring the dump algorithms, see the HP-UX System Administrator's Guide: Configuration Management.
Dump Logical Volume Guidelines
Use the following guidelines when configuring dump logical volumes:
•
HP recommends using logical volumes for dump area rather than disk partitions.
•
A dump logical volume can exist only within the root volume group; that is, the volume group that contains the root logical volume.
•
You can use any secondary swap logical volume as a dump area too, provided the swap area is in the root volume group.
Setting Up Snapshot Logical Volumes for Backup
Beginning with HP-UX 11i v3 March 2010 Update, LVM introduces snapshot logical volumes, which can be used to capture point-in-time images of logical volumes quickly and without requiring as much space as the size of the logical volume. To back up a logical volume while it is in use, a snapshot of the logical volume can be taken and used for backup while the original logical volume remains online and is being modified. The snapshot can be deleted after the backup. The approach, unlike the lvsplit approach, does not require the user to reduce a mirror copy from the original logical volume.
Refer to the LVM Snapshot Logical Volumes white paper for more details on backups using snapshot logical volumes.
Setting Up Different Types of Logical Volumes 23
Planning for Availability
This section describes LVM features that can improve the availability and redundancy of your data.
It addresses the following topics:
•
“Increasing Data Availability Through Mirroring” (page 24)
•
“Increasing Disk Redundancy Through Disk Sparing” (page 27)
•
“Increasing Hardware Path Redundancy Through Multipathing” (page 28)
Increasing Data Availability Through Mirroring
NOTE: Mirroring requires an optional product, HP MirrorDisk/UX.
Mirroring means storing identical copies of data in logical volumes, preferably on separate disks.
This redundancy has several advantages:
•
If you mirror the root file system and swap, the operating system can tolerate a root disk failure because critical data is available on more than one LVM disk.
•
If you mirror the logical volumes used by a particular application, the application continues to run even if a disk fails.
•
If an I/O channel fails, LVM can recover the data from the duplicate source.
•
Mirroring speeds read-intensive applications by enabling the hardware to read data from the most convenient LVM disk.
•
You can back up one copy of the data while another copy continues to run.
Mirroring maps one logical extent to two or more sets of physical extents. The number of logical extents remains constant, but the number of used physical extents (and therefore, occupied disk space) changes depending on the number of mirrored copies. Mirroring increases data protection and system availability, but consumes twice as much disk space (or as many times more as there are mirror copies), so use disk mirroring for volatile, mission-critical data only.
Mirrored logical volumes must belong to the same volume group; you cannot mirror across volume groups.
This section contains the following information:
•
“Mirror Write Behavior Control” (page 24)
•
“Synchronizing a Mirrored Logical Volume” (page 26)
To learn more about basic mirroring tasks, see Disk and File Management Tasks on HP-UX published by Prentice Hall PTR, 1997.
Mirror Write Behavior Control
Three policies govern how mirrored logical extents are written to physical extents: the
These policies can be set using HP SMH, the lvcreate command, or the lvchange command.
Allocation Policy
Mirrored extents can be allocated on physical volumes by strict or nonstrict, contiguous or noncontiguous policies. By default, the allocation policy of mirrored logical volumes is set to strict, noncontiguous.
Strict and Nonstrict Allocation
Strict allocation requires logical extents to be mirrored to physical extents on different physical volumes. Nonstrict allocation allows logical extents to be mirrored to physical extents that may be
24 Configuring LVM
on the same physical volume. The -s y and -s n options to the lvcreate or lvchange commands set strict or nonstrict allocation.
CAUTION: Using nonstrict allocation can reduce the redundancy created by LVM mirroring because a logical extent can be mirrored to different physical extents on the same disk. Therefore, the failure of this one disk makes both copies of the data unavailable.
Contiguous and Noncontiguous Allocation
Contiguous allocation has three characteristics: the physical extents are allocated in ascending order, no gap exists between physical extents within a mirror copy, and all physical extents of a mirror copy reside on a single physical volume. Noncontiguous allocation allows logical extents to be mapped to nonconsecutive physical extents. The -C y and -C n options to the lvcreate or lvchange commands set contiguous or noncontiguous allocation.
NOTE: When the logical volumes allocated from the root volume group are mirrored, each must be set up with contiguous allocation.
Scheduling Policy
The LVM scheduler converts logical I/O requests into one or more physical I/O requests, then schedules them for processing at the hardware level. Scheduling occurs for both mirrored and nonmirrored data.
Two I/O scheduling policies are available: parallel and sequential.
Parallel Scheduling
The parallel scheduling policy is used by default with mirroring for maximum I/O performance.
Parallel scheduling causes mirror operations to write simultaneously to all copies. LVM optimizes reads by reading from the physical volume with the fewest outstanding I/O operations. The -d p option to the lvcreate or lvchange command sets the scheduling policy to parallel for a logical volume.
Sequential Scheduling
The sequential scheduling policy causes mirror write operations to proceed sequentially; that is,
LVM waits for one mirror write to complete before it begins the next mirror write. Likewise, LVM mirrors are read in a predefined order. On a practical level, sequential policy is used only for extreme caution in maintaining consistency of mirrors. The -d s option to the lvcreate or lvchange command sets the scheduling policy to sequential for a logical volume.
Synchronization Policy
You can maintain consistency of mirrored data by enabling or disabling two features of your logical volume: the Mirror Write Cache and Mirror Consistency Recovery.
Synchronization Using Mirror Write Cache
The Mirror Write Cache (MWC) provides a fast resynchronization of data following a system crash or failure, but at a potential performance cost for routine system use.
The MWC keeps track of where I/O writes are occurring on the volume group, and periodically records this activity in an ondisk data structure. An extra disk write is required for every mirrored write not already recorded on the physical volume. This slows down runtime I/O write processing and degrades performance when you access the disk at random; when writing to an area of the disk that is already recorded, the performance is not impaired. Upon system reboot after crash, the operating system uses the MWC to resynchronize inconsistent data blocks quickly.
The frequency of extra disk writes is small for sequentially accessed logical volumes (such as database logs), but increases when access is more random. Therefore, logical volumes containing
Planning for Availability 25
database data or file systems with few or infrequently written large files (greater than 256K) must not use the MWC when runtime performance is more important than crash recovery time.
The -M option to the lvcreate or lvchange command controls the MWC.
Synchronization Using Mirror Consistency Recovery
When the Mirror Consistency Recovery is enabled, LVM does not impact runtime I/O performance.
However, following a system crash, for any logical volumes using Mirror Consistency Recovery, the entire data space resynchronizes when you activate the volume group. Synchronization can be performed in the background without interfering with reboot or access; however, during this time I/O performance and redundancy are degraded.
Synchronization with No Mirror Consistency Mechanism
When Mirror Consistency Recovery is disabled, the operating system's runtime behavior is identical to that of the previous approach. However, following a crash, LVM does not perform any resynchronization of data. This approach is useful for swap volumes and for volumes used by an application (such as a database) with its own means of maintaining or recovering consistent data, such as transaction log files. However, database log files themselves can be configured as a mirrored logical volume to use the MWC.
The -c option to the lvcreate or lvchange command controls the use of the Mirror Consistency
Recovery.
Synchronizing a Mirrored Logical Volume
The data in a mirrored copy or copies of a logical volume can become out of sync, or “stale.” For example, mirrored data becomes stale if LVM cannot access a disk as a result of disk power failure.
Under such circumstances, for each mirrored copy to re-establish identical data, synchronization must occur. Usually, synchronization occurs automatically, but sometimes it must be done manually.
Automatic Synchronization
If you activate a volume group that is not currently active, either automatically at boot time or later with the vgchange command, then LVM automatically synchronizes the mirrored copies of all logical volumes with the Mirror Consistency Recovery policy enabled. It replaces data in physical extents marked as stale with data from nonstale extents. Otherwise, no automatic synchronization occurs and manual synchronization is necessary.
LVM also automatically synchronizes mirrored data in the following cases:
•
When you increase the number of mirror copies of a logical volume using the –m option of lvmerge
, the newly added physical extents are synchronized.
•
When a disk comes back online after experiencing a power failure.
Manual Synchronization
If you look at the status of a logical volume using lvdisplay -v, you can verify if the logical volume contains any stale data. You can then identify which disk contains the stale physical extents.
Manually synchronize the data in one or more logical volumes using either the lvsync command or all logical volumes in one or more volume groups using the vgsync command. For more information, see lvdisplay(1M), vgsync(1M), and lvsync(1M).
Parallel Synchronization
By default, the lvsync command synchronizes logical volumes serially. In other words, it acts on the logical volumes specified on the command line one at a time, waiting until a volume finishes synchronization before starting the next. Starting with the September 2007 release of HP-UX 11i
Version 3, you can use the –T option to synchronize logical volumes in parallel. With the –T option, lvsync spawns multiple threads to simultaneously synchronize all logical volumes belonging to the same volume group, often reducing the total synchronization time.
26 Configuring LVM
TIP: The vgchange, lvmerge, and lvextend commands support the –s option to suppress the automatic synchronization of stale extents. If you are performing multiple mirror-related tasks, you can suppress the extent synchronization until you have finished all the tasks, then run lvsync with –T to synchronize all the mirrored volumes in parallel. For example, you can use vgchange
-s with lvsync -T to reduce the activation time for volume groups with mirrored logical volumes.
For another example, see
“Mirroring the Boot Disk” (page 90)
.
Increasing Disk Redundancy Through Disk Sparing
NOTE: Version 2.x volume groups do not support disk sparing.
Disk sparing requires the optional product HP MirrorDisk/UX.
MirrorDisk/UX is not available for shared LVM environments within a high availability cluster across more than two nodes. You cannot configure sparing within these environments. In such cases, HP recommends that you use hardware mirroring through RAID devices, which can support their own form of sparing.
If a disk containing mirrored data fails, replace the disk as soon as possible, as described in
Troubleshooting and Recovery Procedures” (page 116) . Before you replace the disk, the data in
your logical volume does not have an extra mirrored copy unless you have set up more than one mirror copy. Even with multi–way mirroring, your level of security is reduced because of the loss of one mirror copy.
To prevent this possibility, you can use one or more spare disks within each of your volume groups to serve as substitute devices in the event of disk failure. With this configuration, LVM automatically reconfigures the volume group so that the spare physical volume takes the place of a failed device without any intervention required. That is, a copy of the data from all the logical volumes currently on the failed disk is created on the substitute physical volume. This process is referred to as automatic sparing, or sparing. Sparing occurs while the logical volume remains available to users. You can then schedule the replacement of the failed disk at a time of minimal inconvenience to you and your users. At that time, you copy the data from the spare disk back to the original disk or its replacement and return the spare disk to its role as a standby empty disk.
For sparing to occur, the following conditions must be met:
•
All logical volumes in the volume group must have been configured with strict mirroring so that mirrored copies are maintained on separate disks because LVM copies the data onto the spare from an undamaged disk rather than from the defective disk itself.
•
At least one physical volume must be available as a standby spare; if your last spare is already in use as a result of a prior disk failure, it cannot serve as a currently available spare.
•
The available spare must be at least as large as the failed disk.
The spare physical volume disk space is not available for extent allocation for any other purpose than in the event of serving as a substitute disk in the event of disk failure. Therefore, its physical extents are not included in the counts shown under total PE or free PE in the output of the pvdisplay and vgdisplay commands.
NOTE: If it is important to maintain comparable performance in the event of disk failure, configure a spare physical volume to each bus. However, if more than one disk on the same bus fails, even with this strategy, performance will be impacted.
The pvdisplay and vgdisplay commands provide information on whether a given physical volume is an empty standby spare or currently holding data as a spare in use, along with information on any physical volume that is currently unavailable but had data spared.
Planning for Availability 27
Increasing Hardware Path Redundancy Through Multipathing
Your hardware might provide the capability for dual cabling (dual controllers) to the same physical volume. If so, LVM can be configured with multiple paths to the same physical volume. If the primary link fails, an automatic switch to an alternate link occurs. Using this type of multipathing (also called pvlinks) increases availability.
NOTE:
As of HP-UX 11i Version 3, the mass storage stack supports native multipathing without using LVM pvlinks. Native multipathing provides more load balancing algorithms and path management options than LVM. HP recommends using native multipathing to manage multipathed devices instead of using LVM's alternate links.
HP recommends converting volume groups with alternate links to use native multipathing by the use of persistent DSFs. The /usr/contrib/bin/vgdsf script, vgscan -N command, or vgimport -s -N commands perform this conversion.
For backward compatibility, you can use existing pvlinks. However, you must use legacy device special files for physical volumes and disable native multipathing for those legacy device special files using the scsimgr command. For more information, see the white paper LVM Migration from
Legacy to Agile Naming Model, available at http://www.hp.com/go/hpux-core-docs.
Setting Up Multipathing to a Physical Volume (LVM PVlinks)
To use an alternate link, you can create a volume group with vgcreate, specifying both the primary link and the alternate link device file names. Both links must represent paths to the same physical volume. (Do not run pvcreate on the alternate link; it must already be the same physical volume as the primary link.) When you indicate two device file names, both referring to the same disk using vgcreate, LVM configures the first one as the primary link and the second one as the alternate link.
For example, if a disk has two cables and you want to make one the primary link and the other an alternate link, enter the following command:
# vgcreate /dev/vg01 /dev/dsk/c3t0d0 /dev/dsk/c5t0d0
To add an alternate link to a physical volume that is already part of a volume group, use vgextend to indicate the new link to the physical volume. For example, if /dev/dsk/c2t0d0 is already part of your volume group but you want to add another connection to the physical volume, enter the following command:
# vgextend /dev/vg02 /dev/dsk/c4t0d0
If the primary link fails, LVM automatically switches from the primary controller to the alternate controller. However, you can also tell LVM to switch to a different controller at any time using the pvchange command. For example:
# pvchange -s /dev/dsk/c2t1d0
After the primary link has recovered, LVM automatically switches back from the alternate controller to the original controller unless you previously instructed it not to by using pvchange as follows:
# pvchange -S n /dev/dsk/c2t2d0
NOTE: You can also disable the automatic switchback by using the -p option to pvchange to disable proactive polling. For more information, see pvchange(1M).
View the current links to a physical volume using vgdisplay with the -v option.
28 Configuring LVM
Planning for Performance
This section describes strategies to obtain the best possible performance using LVM. It addresses the following topics:
•
“General Performance Factors” (page 29)
•
“Internal Performance Factors” (page 29)
•
“Increasing Performance Through Disk Striping” (page 31)
•
“Increasing Performance Through I/O Channel Separation” (page 33)
General Performance Factors
The following factors affect overall system performance, but not necessarily the performance of
LVM.
Memory Usage
The amount of memory used by LVM is based on the values used at volume group creation time and on the number of open logical volumes. The largest portion of LVM memory is used for extent maps. The memory used is proportional to the maximum number of physical volumes multiplied by the maximum number of physical extents per physical volume for each volume group.
The other factors to be concerned with regarding memory parameters are expected system growth and number of logical volumes required. You can set the volume group maximum parameters to exactly what is required on the system today. However, if you want to extend the volume group by another disk (or perhaps replace one disk with a larger disk), you must use the vgmodify command.
CPU Usage
Compared to the non-LVM case, no significant impact to system CPU usage (by observing idle time) has been observed.
With LVM, extra CPU cycles are required to perform mirror write consistency cache operations, which is the only configurable option that impacts CPU usage.
Disk Space Usage
LVM reserves some disk space on each physical volume for its own metadata. The amount of space used is proportional to the maximum values used at volume group creation time.
Internal Performance Factors
The following factors directly affect the performance of I/O through LVM.
Scheduling Policy
The scheduling policy is significant only with mirroring. When mirroring, the sequential scheduling policy requires more time to perform writes proportional to the number of mirrors. For instance, a logical volume with three copies of data requires three times as long to perform a write using the sequential scheduling policy, as compared to the parallel policy. Read requests are always directed to only one device. Under the parallel scheduling policy, LVM directs each read request to the least busy device. Under the sequential scheduling policy, LVM directs all read requests to the device shown on the left hand side of an lvdisplay –v output.
Mirror Write Consistency Cache
The purpose of the Mirror Write Consistency cache (MWC) is to provide a list of mirrored areas that might be out of sync. When a volume group is activated, LVM copies all areas with an entry in the MWC from one of the good copies to all the other copies. This process ensures that the mirrors are consistent but does not guarantee the quality of the data.
Planning for Performance 29
On each write request to a mirrored logical volume that uses MWC, LVM potentially introduces one extra serial disk write to maintain the MWC. Whether this condition occurs depends on the degree to which accesses are random.
The more random the accesses, the higher the probability of missing the MWC. Getting an MWC entry can involve waiting for one to be available. If all the MWC entries are currently being used by I/O in progress, a given request might have to wait in a queue of requests until an entry becomes available.
Another performance consideration for mirrored logical volumes is the method of reconciling inconsistencies between mirror copies after a system crash. Two methods of resynchronization are available: Mirror Consistency Recovery (MCR) and none. Whether you use the MWC depends on which aspect of system performance is more important to your environment, run time or recovery time.
For example, a customer using mirroring on a database system might choose "none" for the database logical volume because the database logging mechanism already provides consistency recovery. The logical volume used for the log uses the MWC if quick recovery time was an issue, or MCR if higher runtime performance is required. A database log is typically used by one process and is sequentially accessed, which means it suffers little performance degradation using MWC because the cache is hit most of the time.
Disk Spanning
For disk areas that see the most intensive use by multiple processes, HP recommends spreading the data space for this disk area across as many physical volumes as possible.
Number of Volume Groups
The number of volume groups is directly related to the MWC issues. Because there is only one
MWC per volume group, disk space that is used for many small random write requests must be kept in distinct volume groups if possible when the MWC is being used. This is the only performance consideration that affects the decision regarding the number of volume groups.
Physical Volume Groups
This factor can be used to enforce the separation of different mirror copies across I/O channels.
You must define the physical volume groups. This factor increases the availability by decreasing the single points of failure and provides faster I/O throughput because of less contention at the hardware level.
For example, in a system with several disk devices on each card and several cards on each bus converter, create physical volume groups so that all disks off of one bus converter are in one group and all the disks on the other are in another group. This configuration ensures that all mirrors are created with devices accessed through different I/O paths.
Snapshots and Performance
Logical volumes that have snapshots associated with them could experience an increase in latencies associated with writes. This is also applicable for writes on (writable) snapshots themselves. The increased latencies are seen only for writes that fall on regions (unshare units) that are shared with a successor/predecessor. The reason for this increased latency is the data unsharing that has to precede the actual writes on the original logical volume or a snapshot. Note that the increase in latencies is reduced as data gets unshared between the original logical volume and its snapshots.
Performance is also dependent on the unshare unit size configured for the snapshots of a logical volume. The supported values of the snapshot unshare unit are 512K, 1024K, 2048K, and 4096K.
While choosing the unshare unit size one has to consider the kind of application that will be writing to the snapshots or the original logical volume, and also consider the tradeoff between performance requirements and metadata space that will have to be provisioned on disk.
30 Configuring LVM
The larger the unit of unshare, the more will the latency be when data has to be unshared and the lesser the metadata space needed on disk to track the sharing relationship between snapshots and the original logical volume. If the application performs large and occasional writes, then it is recommended that a larger unshare unit is used. If the writes are small and occasional, then a smaller unshare unit is recommended. If the write pattern is going to be such that they are small and sequential, then again a large unshare unit is recommended because after the first unshare, the following consecutive I/Os that fall within the same unshare unit will not incur the overhead of a unshare operation.
Refer to the LVM Snapshot Logical Volumes white paper for more information about snapshots and performance.
Increasing Performance Through Disk Striping
Disk striping distributes logically contiguous data blocks (for example, chunks of the same file) across multiple disks, which speeds I/O throughput for large files when they are read and written sequentially (but not necessarily when access is random).
The disadvantage of disk striping is that the loss of a single disk can result in damage to many files because files are purposely spread across two or more disks.
Consider using disk striping on file systems where large files are stored, if those files are normally read and written sequentially and I/O performance is important.
When you use disk striping, you create a logical volume that spans multiple disks, allowing successive blocks of data to go to logical extents on different disks. For example, a three-way striped logical volume has data allocated on three disks, with each disk storing every third block of data. The size of each of these blocks is called the stripe size of the logical volume. The stripe size (in K) must be a power of two in the range 4 to 32768 for a Version 1.0 volume group, and a power of two in the range 4 to 262144 for a Version 2.x volume group.
Disk striping can increase the performance of applications that read and write large, sequentially
accessed files. Data access is performed over the multiple disks simultaneously, resulting in a decreased amount of required time as compared to the same operation on a single disk. If all of the striped disks have their own controllers, each can process data simultaneously.
You can use standard commands to manage your striped logical volumes. For example, the lvcreate
, diskinfo, newfs, fsck, and mount commands all work with striped logical volumes.
The following guidelines, most of which apply to LVM disk usage, apply to striped logical volumes for performance reasons:
•
Best performance results from a striped logical volume that spans similar disks. The more closely you match the disks by speed, capacity, and interface type, the better the performance you can expect. When striping across several disks of varying speeds, performance is no faster than that of the slowest disk.
•
If you have more than one interface card or bus to which you can connect disks, distribute the disks as evenly as possible among them. That is, each interface card or bus must have roughly the same number of disks attached to it. You can achieve the best I/O performance when you use more than one bus and interleave the stripes of the logical volume. For example, if you have two buses with two disks on each bus, order the disks so that disk 1 is on bus 1, disk 2 is on bus 2, disk 3 is on bus 1, and disk 4 is on bus 2, as shown in
Planning for Performance 31
Figure 4 Interleaving Disks Among Buses
•
Increasing the number of disks might not improve performance because the maximum efficiency that can be achieved by combining disks in a striped logical volume is limited by the maximum throughput of the file system itself and by the buses to which the disks are attached.
•
Disk striping is highly beneficial for applications with few users and large, sequential transfers.
However, applications that exhibit small, concurrent, random I/O (such as databases) often see no performance gain through disk striping. Consider four disks with a stripe size of 512 bytes. Each 2K request is sent to all disks. One 2K request completes in about the same time when the disk has been striped. However, several 2K requests are all serialized because all the disks must seek for each request. On the nonstriped system, performance might actually be better because each disk might service separate requests in parallel.
Determining Optimum Stripe Size
The logical volume stripe size identifies the size of each of the blocks of data that make up the stripe. You can set the stripe size to a power of two in the range 4 to 32768 for a Version 1.0
volume group, or a power of two in the range 4 to 262144 for a Version 2.x volume group. The default is 8192.
NOTE: The stripe size of a logical volume is not related to the physical sector size of a disk, which is typically 512 bytes.
How you intend to use the striped logical volume determines what stripe size you assign to it.
For best results follow these guidelines:
•
If you plan to use the striped logical volume for an HFS file system, select the stripe size that most closely reflects the block size of the file system. The newfs command enables you to specify a block size when you build the file system and provides a default block size of 8K for HFS.
•
If you plan to use the striped logical volume for a JFS (VxFS) file system, use the largest available size, 64K. For I/O purposes, VxFS combines blocks into extents, which are variable in size and may be very large. The configured block size, 1K by default, is not significant in this context.
•
If you plan to use the striped logical volume as swap space, set the stripe size to 16K for best performance. For more information on configuring swap, see
.
•
If you plan to use the striped logical volume as a raw data partition (for example, for a database application that uses the device directly), the stripe size must be as large or larger than the I/O size for the application.
32 Configuring LVM
You might need to experiment to determine the optimum stripe size for your particular situation.
To change the stripe size, re-create the logical volume.
Interactions Between Mirroring and Striping
Mirroring a striped logical volume improves the read I/O performance in a same way that it does for a nonstriped logical volume. Simultaneous read I/O requests targeting a single logical extent are served by two or three different physical volumes instead of one. A striped and mirrored logical volume follows a strict allocation policy; that is, the data is always mirrored on different physical volumes.
The appendix
“Striped and Mirrored Logical Volumes” (page 157)
provides information about logical volumes that are both striped and mirrored.
Increasing Performance Through I/O Channel Separation
is an approach to LVM configuration requiring that mirrored copies of data reside on LVM disks accessed using separate host bus adapters (HBAs) and cables. I/O channel separation achieves higher availability and better performance by reducing the number of single points of possible hardware failure. If you mirror data on two separate disks, but through one card, your system can fail if the card fails.
You can separate I/O channels on a system with multiple HBAs and a single bus, by mirroring disks across different HBAs. You can further ensure channel separation by establishing a policy called PVG-strict allocation, which requires logical extents to be mirrored in separate physical volume groups. Physical volume groups are subgroups of physical volumes within a volume group.
An ASCII file, /etc/lvmpvg, contains all the mapping information for the physical volume group, but the mapping is not recorded on disk. Physical volume groups have no fixed naming convention; you can name them PVG0, PVG1, and so on. The /etc/lvmpvg file is created and updated using the vgcreate, vgextend, and vgreduce commands, but you can edit the file with a text editor.
I/O channel separation is useful for databases, because it heightens availability (LVM has more flexibility in reading data on the most accessible logical extent), resulting in better performance.
If you define your physical volume groups to span I/O devices, you ensure against data loss even if one HBA fails.
When using physical volume groups, consider using a PVG-strict allocation policy for logical volumes.
Configuring LVM I/O Timeout Parameters
You can configure the following timeout parameters for LVM I/Os.
•
Logical volume timeout (LV timeout).
This controls how long LVM retries a logical I/O after a recoverable physical I/O error. LV timeout can be configured for a specific logical volume using lvchange.
•
Physical volume timeout (PV timeout).
This is the time budget set by LVM for each physical I/O originating from LVM. The mass storage stack underlying LVM manages completion of the physical I/O subject to this timeout, resulting in success or failure for the request. PV timeout can be configured for a specific physical volume using pvchange.
•
Mass storage stack timeout parameters
There are mass storage stack tunables that affect LVM I/O timeout behavior: path_fail_secs and transient_secs.
For details on these timeout parameters, refer to Appendix
“LVM I/O Timeout Parameters” (page 161)
.
Configuring LVM I/O Timeout Parameters 33
Planning for Recovery
Flexibility in configuration, one of the major benefits of LVM, can also be a source of problems in recovery. The following are guidelines to help create a configuration that minimizes recovery time:
•
Keep the number of disks in the root volume group to a minimum; HP recommends using three disks, even if the root volume group is mirrored.
Root volume groups with many disks make reinstallation difficult because of the complexity of recovering LVM configurations of accessory disks within the root volume group.
A small root volume group is quickly recovered. In some cases, you can reinstall a minimal system, restore a backup, and be back online within three hours of diagnosis and replacement of hardware. Another benefit is that exact match to the previous root disk layout is not required.
Three disks in the root volume group are better than two, because of quorum restrictions. With a two-disk root volume group, the loss of one disk can require you to override quorum to activate the volume group; if you must reboot to replace the disk, overriding quorum requires you to interrupt the boot process. If you have three disks in the volume group and they are isolated from each other such that a hardware failure only affects one of them, then failure of only one disk enables the system to maintain quorum.
There are two reasons to expand the root volume group beyond a minimal size.
◦ A very small root disk.
In this case, HP recommends migrating or installing to a larger disk.
◦
Providing for dump-to-swap for large memory systems.
Swap volumes targeted for dump must be in the root volume group. A better solution is to configure an extra dedicated disk for dump up front.
•
Do not use network-based backup programs such as Omniback or Networker for basic root volume group backups. The complexity associated with these utilities can significantly delay the resumption of processing.
HP recommends using Ignite-UX and the make_net_recovery command to back up and recover your root volume group.
•
Create adequate documentation.
Output from ioscan -kf, vgcfgrestore -lv for all groups and vgscan -pv, and lvlnboot -v are very minimal requirements. Recovery from almost any problem is possible if these and output from vgdisplay -v for all groups and lvdisplay -v for all volumes are available. Extent mappings are critical to recovery of LVM volumes with corrupted headers.
Additionally, output from pvdisplay -v for all physical volumes, although not as important, provides complete volume group information. Hard copy is not required or even necessarily practical, but accessibility during recovery is important and should be planned for.
•
Many small groups are better than fewer large groups when configuring auxiliary volume groups.
Reloading dozens of gigabytes of data because one disk is missing out of a group after a root disk rebuild can be difficult. Also the scope of a catastrophic single disk failure within a group is minimized with many small groups.
Size implies complexity. The larger the number of disks in a single group, the more chances an administrator has to create an error that affects the entire group. It is simpler to identify and import smaller groups if necessary. It is also simpler to conceptualize and map smaller groups when required.
34 Configuring LVM
Preparing for LVM System Recovery
To ensure that the system data and configuration are recoverable in the event of a system failure, follow these steps:
1.
Load any patches for LVM.
2.
Use Ignite-UX to create a recovery image of your root volume group. Although Ignite-UX is not intended to be used to back up all system data, you can use it with other data recovery applications to create a method of total system recovery.
3.
Perform regular backups of the other important data on your system.
Without a valid backup, you risk losing some or all of your data.
4.
Regularly print out your system configuration.
The configuration details stored on the system might not be accessible during a recovery. A printed copy is an invaluable reference. HP recommends printing the configuration details once a week and every time a change is made. Some of the commands create large amounts of output. An alternative to printing them is to output the information to a file and then storing the file on tape which enables quick recovery of the information when needed. You can include this configuration file with the backup in step 3.
The easiest way to save the configuration is to set up a cron job to run regularly, so that the system backs it up automatically.
Use the following commands to get a useful output:
/usr/sbin/ioscan -fk
/usr/sbin/vgdisplay -v
/usr/sbin/lvlnboot -v
/usr/sbin/lvdisplay -v /dev/vgXX/lvYY
(for every logical volume)
/usr/sbin/pvdisplay -v /dev/dsk/c#t#d0
(for every LVM disk) lp /etc/fstab
As an alternative, you can write an intelligent script that detects any changes in the configuration and only print out those changes. An example script is included at the end of this section.
5.
Back up the LVM configuration after every configuration change.
The vgcfgbackup command copies the LVM headers from the system area of the disk to a disk file, which resides in the /etc/lvmconf directory. This default directory can be changed for volume group Version 2.x by configuring a new path in the LVMP_CONF_PATH_NON_BOOT variable in the /etc/lvmrc file (see vgcfgbackup(1M) for more information). After this information is stored in a disk file, it can be backed up to tape during file system backups.
The information in this file enables you to replace the LVM headers on the disk in the event of the disk being replaced or your LVM configuration becoming corrupted.
It is important that these configuration backups are taken whenever you make a change to any part of the LVM configuration. By default all the commands perform a backup so a manual vgcfgbackup after each command is not required.
Do this task on a regular basis, whether you have made changes or not. Enter the following command:
# /usr/sbin/vgcfgbackup /dev/vgXX (for every volume group)
Planning for Recovery 35
NOTE: For volume group Version 2.2 and higher: volume groups that have snapshots on which data unsharing is occurring, the LVM configuration backup file might not always be in sync with the LVM metadata on disk. LVM ensures that the configuration for volume group
Version 2.2 and higher is the latest by automatically backing it up during deactivation, unless backup has been disabled by the -A n option. If the configuration backup during deactivation will be bypassed, then to ensure that the volume group's configuration is the latest, it is recommended that you close all the logical volumes of the volume group and back up the configuration using vgcfgbackup prior to deactivating the volume group.
6.
Update the boot structures after every change to the root volume group.
This task is only required if you are using LVM on your boot disk. Whenever you make changes to the root volume group, which is usually named /dev/vg00, the BDRA on the boot disk must be updated. This is normally performed automatically by the LVM commands. To update the BDRA manually, enter the following command:
# /usr/sbin/lvlnboot -R
See
Chapter 4: Troubleshooting LVM
for detailed information about recovery.
36 Configuring LVM
Example Script for LVM Configuration Recording
The following example script captures the current LVM and I/O configurations. If they differ from the previously captured configuration, the script prints the updated configuration files and notifies the system administrator.
#!/usr/bin/ksh
WORKDIR=/lvmbackup # directory is regularly backed up
LOG=$WORKDIR/log
SYSADM=root if [ -f "$LOG" ] then
rm -f "$LOG" fi if [ ! -d "$WORKDIR" ] then
echo "missing directory $WORKDIR" exit 1 fi cd $WORKDIR
/usr/sbin/vgdisplay -v -F > vgdisplay.new
LVMVGS=`grep vg_name vgdisplay.new | cut -d: -f1 | cut -d= -f2`
LVMPVOLS=`grep pv_name vgdisplay.new | cut -d: -f1 | cut -d= -f2 | cut -d, -f1`
LVMLVOLS=`grep lv_name vgdisplay.new | cut -d: -f1 | cut -d= -f2`
/usr/sbin/pvdisplay -v $LVMPVOLS > pvdisplay.new
/usr/sbin/lvdisplay -v $LVMLVOLS > lvdisplay.new
/usr/sbin/lvlnboot -v > lvlnboot.new 2> /dev/null
/usr/sbin/ioscan -fk > ioscan.new
cp /etc/fstab fstab.new
for CURRENT in *new.
do
ORIG=${CURRENT%.new}
if diff $CURRENT $ORIG > /dev/null then
# files are the same....do nothing
rm $CURRENT
else
# files differ...make the new file the current file, move old
# one to file.old.
echo `date` "The config for $ORIG has changed." >> $LOG
echo "Copy of the new $ORIG config has been printed" >> $LOG
lp $CURRENT
mv $ORIG ${ORIG}old.
mv $CURRENT $ORIG
fi done if [ -s "$LOG" ] then
mailx -s "LVM configs have changed" $SYSADM < $LOG fi exit 0
Planning for Recovery 37
3 Administering LVM
This section contains information on the day-to-day operation of LVM. It addresses the following topics:
•
“Administration Tools” (page 38)
•
“Displaying LVM Information” (page 40)
•
•
“Moving and Reconfiguring Your Disks” (page 70)
•
“Migrating a Volume Group to New Disks: vgmove” (page 95)
•
“Migrating a Logical Volume to New Disks: lvmove” (page 96)
•
“Administering File System Logical Volumes” (page 97)
•
“Administering Swap Logical Volumes” (page 101)
•
“Administering Dump Logical Volumes” (page 102)
•
“Creating and Administering Snapshot Logical Volumes” (page 103)
•
“Managing the lvmpud Daemon” Page 105
•
Administration Tools
HP-UX provides two tools to manage your LVM configuration:
•
HP System Management Homepage (HP SMH): An HP-UX tool that provides an easy-to-use
GUI for performing most LVM tasks. HP SMH minimizes or eliminates the need for detailed knowledge of administration commands, thus saving time. Use HP SMH to manage your LVM configuration whenever possible, especially when performing a new task. HP SMH can help you with the following tasks:
◦ Creating or removing volume groups
◦
Adding or removing disks within volume groups
◦ Activating and deactivating volume groups
◦
Exporting and importing volume groups
◦ Creating, removing, or modifying logical volumes
◦
Increasing the size of logical volumes
◦ Creating or increasing the size of a file system in a logical volume
◦
Creating and modifying mirrored logical volumes
◦ Creating striped logical volumes
◦
Splitting a mirrored logical volume and merging a mirror copy
◦ Adding and removing mirror copies within mirrored logical volumes
◦
Creating and modifying physical volume groups
To use HP SMH, enter the command /usr/sbin/smh.
For help using HP SMH, see the HP SMH online help.
•
LVM command-line interface: LVM has a number of low-level user commands to perform LVM tasks, described in
“Physical Volume Management Commands” (page 39) , “Volume Group
38 Administering LVM
Management Commands” (page 39) , and
“Logical Volume Management Commands”
.
The following tables provide an overview of which commands perform a given task. For more information, see the LVM individual manpages.
Table 4 Physical Volume Management Commands
Task
Changing the characteristics of a physical volume in a volume group
Creating a physical volume for use in a volume group
Displaying information about physical volumes in a volume group
Moving data from one physical volume to another
Removing a physical volume from LVM control
Checking or repairing a physical volume
Checking if a disk volume is under LVM control
1 The pvck command is not supported on Version 2.x volume groups.
Table 5 Volume Group Management Commands
Command pvchange pvcreate pvdisplay pvmove pvremove pvck
1 lvmchk
Task
Creating a volume group
Removing a volume group
Command vgcreate vgremove
Activating, deactivating, or changing the characteristics of a volume group vgchange
Modifying the configuration parameters of a volume group; handling physical volume size changes
Backing up volume group configuration information vgmodify vgcfgbackup
Restoring volume group configuration from a configuration file
Displaying information about volume groups
Exporting a volume group and its associated logical volumes vgcfgrestore vgdisplay vgexport
Importing a volume group onto the system; adding an existing volume group back into the LVM configuration files vgimport
Scanning all physical volumes for logical volumes and volume groups; recovering the LVM configuration files vgscan
Adding a disk to a volume group
Removing a disk from a volume group vgextend vgreduce
Synchronizing mirrored logical volumes in a volume group
Modifying the volume group ID on a physical volume vgsync vgchgid
Migrating a volume group from legacy to persistent device files vgdsf
Converting persistent device special files in a volume group to cluster device special files. (See note after table.) vgcdsf
1
Displaying limits associated with a volume group version lvmadm
Handling online shared LVM reconfiguration, and pre-allocation of extents for space-efficient snapshots lvmpud
Administration Tools 39
Table 5 Volume Group Management Commands (continued)
Task
Migrating a volume group to a different volume group version
Command vgversion
Migrating a volume group to new disks vgmove
1 To convert the cDSFs of a volume group in a particular node back to their corresponding persistent DSFs, use the vgscan -f command. For example:
# vgscan -f vgtest
*** LVMTAB has been updated successfully.
Repeat the above command on all the nodes in the cluster where this shared volume group is present (i.e., imported). Use the lvmadm -l command to verify the conversion of cDSFs to persistent DSF.
Table 6 Logical Volume Management Commands
Task
Creating a logical volume
Modifying a logical volume
Displaying information about logical volumes
Increasing the size of a logical volume by allocating disk space
Command lvcreate lvchange lvdisplay lvextend
Migrating a logical volume to new disks
Decreasing the size of a logical volume lvmove lvreduce
Removing the allocation of disk space for one or more logical volumes within a volume group lvremove
Preparing a logical volume to be a root, primary swap, or dump volume; updating the boot information on the boot physical volume lvlnboot
1
Removing the link that makes a logical volume a root, primary swap, or dump volume lvrmboot
1
Splitting a mirrored logical volume into two logical volumes
Merging two logical volumes into one mirrored logical volume lvsplit lvmerge
Synchronizing mirror copies in a mirrored logical volume lvsync
1 The lvlnboot and lvrmboot commands are not supported on Version 2.0 and 2.1 volume groups.
The command-line interface is more powerful—and thus more dangerous—than HP SMH and offers options that are not available using HP SMH. For example, the following tasks cannot currently be done by HP SMH. For these tasks, use the HP-UX commands:
◦
“Creating a Spare Disk” (page 76)
◦
“Reinstating a Spare Disk” (page 77)
◦
“Synchronizing a Mirrored Logical Volume” (page 26)
◦
“Moving Data to a Different Physical Volume” (page 73)
◦
“Disk Troubleshooting and Recovery Procedures” (page 116)
The remainder of this chapter explains how to do LVM tasks using HP-UX commands. However,
HP SMH is the tool of choice for most administration work.
Displaying LVM Information
To display information about volume groups, logical volumes, or physical volumes, use one of three commands. Each command supports the -v option to display detailed output and the -F option to help with scripting.
40 Administering LVM
NOTE: For volume group Version 2.2 or higher, when snapshots are involved, additional fields are displayed by these commands. See the individual command manpages for full description of the fields displayed. The
“Creating and Administering Snapshot Logical Volumes” (page 103)
section provides a summary of additional data displayed for snapshots.
Information on Volume Groups
Use the vgdisplay command to show information about volume groups. For example:
# vgdisplay -v vg01
-- Volume groups --
VG Name /dev/vg01
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 1
Open LV 1
Max PV 16
Cur PV 1
Act PV 1
Max PE per PV 1016
VGDA 2
PE Size (Mbytes) 4
Total PE 508
Alloc PE 508
Free PE 0
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 1.0
VG Max Size 1082g
VG Max Extents 69248
-- Logical volumes --
LV Name /dev/vg01/lvol1
LV Status available/syncd
LV Size (Mbytes) 2032
Current LE 125
Allocated PE 508
Used PV 1
-- Physical volumes --
PV Name /dev/disk/disk42
PV Status available
Total PE 508
Free PE 0
Autoswitch On
Proactive Polling On
Use the vgdisplay command to verify whether the LVM configuration in memory has problems.
If the LVM configuration is working properly, there are no error messages, and the display shows the following:
•
The status is available (or available/exclusive for Serviceguard volume groups).
•
All the physical volumes are active; that is, the current number of physical volumes (Cur PV) is equal to number of active physical volumes (Act PV).
•
All the logical volumes are open; that is, Cur LV is equal to Open LV.
Information on Physical Volumes
Use the pvdisplay command to show information about physical volumes. For example:
Displaying LVM Information 41
# pvdisplay -v /dev/disk/disk47
-- Physical volumes --
PV Name /dev/disk/disk47
VG Name /dev/vg00
PV Status available
Allocatable yes
VGDA 2
Cur LV 9
PE Size (Mbytes) 4
Total PE 1023
Free PE 494
Allocated PE 529
Stale PE 0
IO Timeout (Seconds) default
Autoswitch On
Proactive Polling On
-- Distribution of physical volume --
LV Name LE of LV PE for LV
/dev/vg00/lvol1 25 25
/dev/vg00/lvol2 25 25
/dev/vg00/lvol3 50 50
--- Physical extents ---
PE Status LV LE
0000 current /dev/vg00/lvol1 0000
0001 current /dev/vg00/lvol1 0001
0002 current /dev/vg00/lvol1 0002
...
1021 free 0000
1022 free 0000
If the physical volume is functioning properly, Stale PE is 0.
Information on Logical Volumes
Use the lvdisplay command to show information about logical volumes. For example:
# lvdisplay -v /dev/vg00/lvol1
-- Logical volumes --
LV Name /dev/vg00/lvol1
VG Name /dev/vg00
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 100
Current LE 25
Allocated PE 25
Stripes 0
Stripe Size (Kbytes) 0
Bad block off
Allocation strict/contiguous
IO Timeout (Seconds) default
-- Distribution of logical volume --
PV Name LE on PV PE on PV
/dev/disk/disk42 25 25
-- Logical extents --
LE PV1 PE1 Status 1
0000 /dev/disk/disk42 0000 current
0001 /dev/disk/disk42 0001 current
0002 /dev/disk/disk42 0002 current
42 Administering LVM
Common LVM Tasks
The section addresses the following topics:
•
“Initializing a Disk for LVM Use” (page 43)
•
“Creating a Volume Group” (page 44)
•
“Migrating a Volume Group to a Different Version: vgversion” (page 46)
•
“Adding a Disk to a Volume Group” (page 51)
•
“Removing a Disk from a Volume Group” (page 51)
•
“Creating a Logical Volume” (page 52)
•
“Extending a Logical Volume” (page 53)
•
“Reducing a Logical Volume” (page 55)
•
“Adding a Mirror to a Logical Volume” (page 55)
•
“Removing a Mirror from a Logical Volume” (page 56)
•
“Renaming a Logical Volume” (page 56)
•
“Removing a Logical Volume” (page 57)
•
“Exporting a Volume Group” (page 57)
•
“Importing a Volume Group” (page 58)
•
“Modifying Volume Group Parameters” (page 58)
•
“Quiescing and Resuming a Volume Group” (page 65)
•
“Renaming a Volume Group” (page 66)
•
“Splitting a Volume Group” (page 67)
•
“Removing a Volume Group” (page 68)
•
“Backing Up a Mirrored Logical Volume” (page 68)
•
“Backing Up and Restoring Volume Group Configuration” (page 69)
Initializing a Disk for LVM Use
CAUTION: Initializing a disk using pvcreate results in the loss of any existing data currently on the disk.
NOTE: If your disk is already connected to the system, skip the first four steps of this procedure.
To initialize a disk for use as a physical volume, follow these steps:
1.
Shut down and power off the system.
2.
Connect the disk to the system and power supply. For detailed information and instructions on adding a particular type of disk, see your device documentation.
3.
Power on the disk.
4.
Boot the system.
5.
Determine the disk's associated device file. To show the disks attached to the system and their device file names, enter the ioscan command with the -f, -N, and -n options. For example:
# ioscan -f -n -N -C disk
For more information, see ioscan(1M).
Common LVM Tasks 43
6.
Initialize the disk as a physical volume using the pvcreate command. For example:
# pvcreate /dev/rdisk/disk3
Use the character device file for the disk.
If you are initializing a disk for use as a boot device, add the -B option to pvcreate to reserve an area on the disk for a LIF volume and boot utilities. If you are creating a boot disk on an HP Integrity server, make sure the device file specifies the HP-UX partition number (2).
For example:
# pvcreate -B /dev/rdisk/disk3_p2
NOTE: Version 2.0 and 2.1 volume groups do not support bootable physical volumes. Do not use the -B option if the disk will be used in a Version 2.0 or 2.1 volume group.
After a disk is initialized, it is called a physical volume.
Creating a Volume Group
To create a volume group, use the vgcreate command. The options differ depending on whether you are creating a Version 1.0 volume group or a Version 2.x volume group.
Creating the Volume Group Device File
As of the March 2008 release of HP-UX 11i Version 3, the vgcreate command automatically creates the device file /dev/vgname/group to manage the volume group, regardless of the volume group version. If you are using an HP-UX release before March 2008, or if you want to specify the minor number of the group file, you must create /dev/vgname/group before running the vgcreate command.
If the group file does not exist and vgcreate can not create it, vgcreate displays the following message: vgcreate: "/dev/vgname/group": not a character device.
To create the volume group device file, follow these steps:
1.
Create a directory for the volume group. For example:
# mkdir /dev/vgname
By convention, vgname is vgnn, where nn is a unique number across all volume groups.
However, you can choose any unique name up to 255 characters.
2.
Create a device file named group in the volume group directory with the mknod command.
For example:
# mknod /dev/vgname/group c major 0xminor
The c following the device file name specifies that group is a character device file.
major
is the major number for the group device file. For a Version 1.0 volume group, it is
64. For a Version 2.x volume group, it is 128.
minor
is the minor number for the group file in hexadecimal. For a Version 1.0 volume group, minor has the form 0xnn0000, where nn is a unique number across all Version 1.0
volume groups. For a Version 2.x volume group, minor has the form 0xnnn000, where nnn is a unique number across all Version 2.x volume groups.
For more information on mknod, see mknod(1M); for more information on major numbers and minor numbers, see
“Device Number Format” (page 15) .
Creating a Version 1.0 Volume Group
To create a Version 1.0 volume group, use the vgcreate command, specifying each physical volume to be included. For example:
# vgcreate /dev/vgname /dev/disk/disk3
44 Administering LVM
Use the block device file to include each disk in your volume group. You can assign all the physical volumes to the volume group with one command, or create the volume group with a single physical volume. No physical volume can already be part of an existing volume group.
You can set volume group attributes using the following options:
-V 1.0
Version 1.0 volume group (default)
-s pe_size
Size of a physical extent in MB (default 4)
-e max_pe
Maximum number of physical extents per physical volume (default 1016)
-l max_lv
Maximum number of logical volumes (default 255)
-p max_pv
Maximum number of physical volumes (default 255)
The size of a physical volume is limited by pe_size times max_pe. If you plan to assign a disk larger than approximately 4 GB (1016 * 4 MB) to this volume group, use a larger value of pe_size or max_pe.
The size of the LVM metadata on each disk depends on max_lv, max_pv, and max_pe. If the vgcreate options would cause the metadata to exceed its available space, vgcreate does not create the volume group. You must select new values of max_lv, max_pv, and max_pe. For example, if you plan to use disks larger than 100 GB, consider reducing max_pv. For recommendations on choosing an optimal extent size, see
Creating a Version 2.x Volume Group
For Version 2.x volume groups, the vgcreate command does not require maximum values for the number of physical volumes (-p), number of logical volumes (-l), or extents per physical volume (-e). Instead you must specify only the extent size (-s) and the maximum size to which the volume group can grow (-S). For example:
# vgcreate -V 2.0 -s pe_size -S vg_size /dev/vgname /dev/disk/disk3
Use the block device file to include each disk in your volume group. You can assign all the physical volumes to the volume group with one command, or create the volume group with a single physical volume. No physical volume can already be part of an existing volume group.
You must use the following options:
-V 2.x
Version 2.x (such as 2.0, 2.1, or 2.2) volume group
-s pe_size
Size of a physical extent in MB
-S vg_size
Maximum future size of the volume group
The size of a volume group is the sum of the user data space on all physical volumes assigned to the volume group. vg_size is not the size of the volume group at creation; it is the size to which the volume group can grow in the future.
This value can be specified in megabytes, gigabytes, terabytes, or petabytes, by adding the character m, g, t, or p, respectively. For example, to specify a maximum size of two terabytes, use -S 2t.
In a Version 2.x volume group, the number of physical extents in a volume group has an architectural limit, so your choice of physical extent size affects the maximum size of the volume group. To display the maximum volume group size for a given physical extent size, use the -E option to vgcreate with the -s option. For example:
# vgcreate -V 2.0 -E -s 256
Max_VG_size=2p:extent_size=256m
Conversely, to display the minimum physical extent size for a given volume group size, use the
-E option to vgcreate with -S. For example:
# vgcreate -V 2.0 -E -S 2t
Max_VG_size=2t:extent_size=1m
For volume group Version 2.2 or higher, a new vgcreate-U option is introduced to configure the size of the unshare unit for snapshots in the volume group. Once the unshare unit size is
Common LVM Tasks 45
specified, it cannot be changed. The default unshare unit size is 1024 KB if the -U option is not used. Below is an example of vgcreate with the -U option:
# vgcreate -V 2.2 -S 4t -s 8 -U 2048 /dev/vg01 /dev/disk/disk20
Migrating a Volume Group to a Different Version: vgversion
Beginning with the HP-UX 11i v3 March 2009 Update, LVM offers the new command vgversion, which enables you to migrate the current version of an existing volume group to any other version, except for migrating to Version 1.0. Therefore, the following migrations are supported:
Table 7 Supported Volume Group Version Migrations
Original Version
1.0
1.0
2.x
Supported Target Version
2.0 or 2.1 (migration does not support boot, swap, dump PVs)
2.2 (migration does not support boot PVs)
2.y
NOTE: Because Version 2.0 and 2.1 volume groups do not support bootable physical volumes, and because at least one physical volume in the root volume group must be a bootable physical volume, the root volume group, usually named vg00, cannot be migrated to Version 2.0 or 2.1.
Version 2.2 (or higher) volume groups do support bootable PVs; however, the migration of Version
1.0 bootable PVs to Version 2.2 (or higher) is currently not supported for the HP-UX 11i v3 March
2010 Update.
For detailed information on the versions of volume groups and the benefits of migrating your volume groups to Version 2.x, see
“LVM Volume Group Versions” (page 11)
.
For detailed information on the vgversion command, see the vgversion(1M) manpage.
Determining the Version of a Volume Group
To determine the current version of an existing volume group, use the vgdisplay command:
# vgdisplay vg01
--- Volume groups ---
VG Name /dev/vg01
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 4
Open LV 4
Max PV 16
Cur PV 1
Act PV 1
Max PE per PV 1279
VGDA 2
PE Size (Mbytes) 4
Total PE 1279
Alloc PE 100
Free PE 1179
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 1.0
VG Max Size 81856m
VG Max Extents 20464
The VG Version field indicates the target volume group is Version 1.0
46 Administering LVM
Command Syntax
The vgversion syntax is: vgversion [-r] [-v] –V [-U unshare_unit] vg_version_new vg_name where
-r
-v
-U unshare_unit
-V vg_version_new
vg_name
is Review mode. This allows you to review the operation before performing the actual volume group version migration.
is Verbose mode.
sets the unit at which data will be unshared between a logical volume and its snapshots, in the new volume group. This is only applicable for migration to volume group Version 2.2 or higher. For more information about snapshots see
“Creating and Administering Snapshot
.
is the new version to which you are migrating (2. x).
is the target volume group (for example, vg01)
TIP:
•
For a successful migration, the target volume group must meet certain conditions at execution time; for example, the target volume group must be inactive. However, these conditions do
not need to be met when you are using Review mode (the –r option). For more information on using the –r option, see
“Review Mode: vgversion -r” (page 47) .
•
Like other commands that run at the HP-UX shell level, the exit value of vgversion for a failed migration or failed migration review will be non-zero:
# echo $?
1
Review Mode: vgversion -r
vgversion allows you to review (–r) its stdout and stderr messages to determine whether an attempted migration will succeed or fail without performing the actual migration.
Migration Success
In Review mode, when the migration will succeed, you should get messages that conclude with text similar to the following:
...
Volume Group version can be successfully changed to ...
Review complete. Volume group not modified.
Migration Failure
A migration of a volume group can fail for various reasons, including:
• the target volume group must not be active
• the target volume group must be cluster-unaware
• no physical volumes of the target volume group should be used as the cluster lock disk
• the physical volumes of the volume group must have enough space for the new metadata
• the existing volume group has any features that are not supported in the target volume group version
(For a list of all conditions, see the latest vgversion(1M) manpage.)
When the migration will fail, the vgversion –r output messages should indicate the problem and possible solutions. For example, if you are migrating a volume group from Version 1.0 to 2.1,
Common LVM Tasks 47
Version 2.1 requires more metadata. Thus, it is possible that there is not enough space in the LUN for the increase in metadata. In this example, vgversion –r should display the following:
#vgversion -V 2.1 -r -v vg01
Performing "vgchange -a r -l -p -s vg01" to collect data
Activated volume group
Volume group "vg01" has been successfully activated.
The space required for Volume Group version 2.1 metadata on Physical Volume
/dev/disk/disk12 is 8448 KB, but available free space is 1024 KB.
0 free user extents from the end of the Physical Volume /dev/disk/disk12 will be utilized to accommodate the Volume Group version 2.1 metadata.
vgversion: More space for metadata is required. Take one of the following actions:
1. Free 8 extents more from the end of the Physical Volume
2. Increase the disk size by 7424 KB to avoid using the free user extents
3. Increase the disk size by 7424 KB and use the free user extents
Warning: Volume Group version 2.1 does not support bad block relocation. The bad block relocation policy of all logical volumes will be set to NONE.
Deactivating Volume Group "vg01"
Volume group "vg01" has been successfully deactivated.
Review complete. Volume group not modified
Using one of the solutions displayed or using a solution of your own, you must resolve the problem in order for the migration to be successful. In this case, we could increase the LUN size to allow for the additional metadata. After you believe you have resolved the problem(s) displayed, you can try vgversion –r again to determine whether the migration will be successful. Once the vgversion –r output shows a successful migration, you can execute the actual migration using vgversion without the –r option.
TIP: Use the –v (Verbose) option along with the –r (Review mode) option to display full details of the problem. In the above example, if you omit the –v option, the above output would not include the following details:
The space required for Volume Group version 2.1 metadata on Physical Volume
/dev/disk/disk12 is 8448 KB, but available free space is 1024 KB.
Example of Migrating a Volume Group to a Different Version
In this example:
•
The target volume is vg01.
•
We will be migrating it from version 1.0 to 2.1.
•
Assume that the target volume group is currently cluster-unaware but activated.
The process for performing a migration are:
1.
Verify the current version of the target volume group:
# vgdisplay vg01 | grep -i version
VG Version 1.0
This shows the current version is 1.0.
2.
Review the migration:
# vgversion -r -v -V 2.1 vg01
The space required for Volume Group version 2.1 metadata on
Physical Volume /dev/disk/disk12 is 8448 KB, but available free space is 1024 KB.
8 free user extents from the end of the Physical Volume
/dev/disk/disk12 will be utilized to accommodate the Volume Group version 2.1 metadata.
Warning: Volume Group version 2.1 does not support bad block
48 Administering LVM
relocation. The bad block relocation policy of all logical volumes will be set to NONE.
Volume Group version can be successfully changed to 2.1
Review complete. Volume group not modified
3.
After messages from the review indicate a successful migration, you can begin the actual migration: a.
Unlike in Review mode, the target volume group must meet certain conditions at execution time, including being de-activated. Since the target volume group is active, we must de-activate it before performing the actual migration:
# vgchange -a n vg01 b.
Now, you can perform the actual migration:
# vgversion -v -V 2.1 vg01
Performing "vgchange -a y -l -p -s vg01" to collect data
Activated volume group
Volume group "vg01" has been successfully activated.
The space required for Volume Group version 2.1 metadata on
Physical Volume /dev/disk/disk12 is 8448 KB, but available free space is 1024 KB.
8 free user extents from the end of the Physical Volume /dev/disk/disk12 will be utilized to accommodate the Volume Group version 2.1 metadata.
Warning: Volume Group version 2.1 does not support bad block relocation. The bad block relocation policy of all logical volumes will be set to NONE.
Old Volume Group configuration for "/dev/vg01" has been saved in
"/etc/lvmconf/vgversion_vg01/vg01_1.0.conf"
Deactivating Volume Group "vg01"
Volume group "vg01" has been successfully deactivated.
New Volume Group configuration for "/dev/vg01" has been saved in
"/etc/lvmconf/vgversion_vg01/vg01_2.1.conf"
Removing the Volume Group /dev/vg01 from /etc/lvmtab
Applying the configuration to all Physical Volumes from
"/etc/lvmconf/vgversion_vg01/vg01_2.1.conf"
Volume Group configuration has been restored to /dev/rdisk/disk12
Creating the Volume Group of version 2.1 with minor number 0x5000.
Adding the Volume Group /dev/vg01 to /etc/lvmtab_p
Original Volume Group Version was 1.0
New Volume Group Version is 2.1
Volume Group version has been successfully changed to 2.1"
The output shows that the migration was successful.
4.
To verify the migration: a.
You can use vgdisplay to verify the migration. vgdisplay requires its target volume group to be activated. Since the target volume group could not be active during the migration, we must activate it:
# vgchange -a y vg01 b.
Once activated, we can use vgdisplay to verify the migration:
# vgdisplay vg01 | grep -i version
VG Version 2.1
The version shows the correct final version of 2.1.
Migration Recovery
When running vgversion, recovery configuration files and a recovery script are created so that you can restore the target volume group to its original version in case there are problems during the actual migration.
Common LVM Tasks 49
CAUTION: The recovery script should be run only in cases where the migration unexpectedly fails, such as an interruption during migration execution.
•
The recovery script should not be used to “undo” a successful migration. For a successful vgversion migration, you should use only a subsequent vgversion execution (and not the recovery script) to reach the newly desired volume group version. Note that a migration
to 1.0 is not supported, so no return path is available once a migration from Version 1.0 to
Version 2.x is successful.
•
Further, when needed, the recovery script should be run only immediately after the attempted migration fails. Because the recovery script contains only configuration information corresponding to the time of migration, any volume group configuration changes subsequent to the migration would not be included in the recovery script, and therefore will be lost when the recovery script is run.
File Location
The backup files, including the recovery script, exist in
/etc/lvmconf/vgversion_vg_name where
vg_name
is the name of the target volume group at the time of the actual conversion.
Command Syntax
The syntax for the recovery script is: vgversion_vg_name_restore vg_name_vg_version_old.conf
where
vg_name
is the name of the target volume group
vg_version_old
is the original version number of the volume group (1.0 or 2.x)
NOTE: The target volume group should be de-activated or all physical volumes of the target volume group should be detached prior to running the recovery script.
Example Recovery
Assume there was an unexpected interruption, such as a power failure, during the above migration of vg01 and that we need to return the volume group to its pre-migration state, where the volume group was of version 1.0:
1.
If needed, de-activate the target volume group:
# vgchange -a n vg01
2.
cd to the directory where the configuration backup files and recovery script exist. Using the above file location naming convention:
# cd /etc/lvmconf/vgversion_vg01
3.
Run the recovery script. Using the above syntax:
# vgversion_vg01_restore vg01_1.0.conf
4.
Once the recovery has successfully completed, you can now re-attempt the migration using vgversion
:
# vgversion -v -V 2.1 vg01
For more information on recovery, see the vgversion(1M) manpage.
50 Administering LVM
NOTE: Once the recovery is complete using the restore script, an immediate vgversion operation in review mode will fail. You need to de-active the volume group and activate it again before running vgversion in review mode. This reset of volume group is not needed for a vgversion operation not in review mode.
Adding a Disk to a Volume Group
Often, as new disks are added to a system, they must be added to an existing volume group rather than creating a whole new volume group. If new disks are being added for user data, such as file systems or databases, do not to add them to the root volume group. Instead, leave the root volume group as only the disks containing the root file system and system file systems such as /usr, /tmp, and so on.
To add a disk to a volume group, follow these steps:
1.
Initialize the disk as a physical volume by using the pvcreate command, as described in
“Initializing a Disk for LVM Use” (page 43) .
2.
Add the physical volume to the volume group using the vgextend command and the block device file for the disk. For example:
# vgextend /dev/vgname /dev/disk/disk3
Removing a Disk from a Volume Group
To remove a disk from a volume group, follow these steps:
1.
Make sure the disk has no assigned physical extents, using the pvdisplay command. For example:
# pvdisplay /dev/disk/disk3
-- Physical volumes --
PV Name /dev/disk/disk3
VG Name /dev/vg00
PV Status available
Allocatable yes
VGDA 2
Cur LV 9
PE Size (Mbytes) 4
Total PE 1023
Free PE 494
Allocated PE 529
Stale PE 0
IO Timeout (Seconds) default
Autoswitch On
Proactive Polling On
-- Distribution of physical volume --
LV Name LE of LV PE for LV
/dev/vg00/lvol1 25 25
/dev/vg00/lvol2 25 25
/dev/vg00/lvol3 50 50
--- Physical extents ---
PE Status LV LE
0000 current /dev/vg00/lvol1 0000
0001 current /dev/vg00/lvol1 0001
0002 current /dev/vg00/lvol1 0002
1021 free 0000
1022 free 0000
Common LVM Tasks 51
Check that the number of free physical extents (Free PE) matches the total number of physical extents (Total PE). If they are not the same, do one of the following tasks:
•
Move the physical extents onto another physical volume in the volume group. See
Data to a Different Physical Volume” (page 73)
.
•
Remove the logical volumes from the disk, as described in
(page 57) . The logical volumes with physical extents on the disk are shown at the end of
the pvdisplay listing.
2.
After the disk no longer holds any physical extents, use the vgreduce command to remove it from the volume group. For example:
# vgreduce /dev/vgnn /dev/disk/disk3
IMPORTANT: If you are using LVM pvlinks, as described in
Redundancy Through Multipathing” (page 28)
, you must run the vgreduce command for each link to the disk.
Creating a Logical Volume
To create a logical volume, follow these steps:
1.
Decide how much disk space the logical volume needs.
For example, you can add 200 MB of device swap space, or you might have a new project that you expect to grow to 10 GB.
2.
Find a volume group that has adequate free space.
To determine if there is sufficient disk space available for the logical volume within a volume group, use the vgdisplay command to calculate this information. vgdisplay outputs data on one or more volume groups, including the physical extent size (under PE Size (MBytes)) and the number of available physical extents (under Free PE). By multiplying these two figures, you get the number of megabytes available within the volume group. For more information, see vgdisplay(1M).
3.
Create the logical volume using lvcreate. For example:
# lvcreate -L size_in_MB /dev/vgnn
This command creates the logical volume /dev/vgnn/lvoln with LVM automatically assigning the n in lvoln.
When LVM creates the logical volume, it creates block and character device files for that logical volume and places them in the /dev/vgnn directory.
Creating a Striped Logical Volume
To create a striped logical volume, use lvcreate with the -i and the -I options to specify the number of disks and stripe width, respectively. For example, suppose you want to stripe across three disks with a stripe size of 32K. Your logical volume size is 240 MB. To create the striped logical volume, enter the following command:
# lvcreate -i 3 -I 32 -l 240 -n lvol1 /dev/vg01
The lvcreate command automatically rounds up the size of the logical volume to a multiple of the number of disks times the extent size. For example, if you have three disks you want to stripe across and the extent size is 4 MB, even though you indicate a logical volume size of 200 MB
(-L 200), lvcreate creates a 204 MB logical volume because 200 is not a multiple of 12.
52 Administering LVM
NOTE: When you stripe across multiple disks, the striped volume size cannot exceed the capacity of the smallest disk multiplied by the number of disks used in the striping.
Creating a Mirrored Logical Volume
To create a mirrored logical volume, use lvcreate with the -m option to select the number of mirror copies. To control how the mirror copies are managed, choose from the following options:
Strict, Nonstrict, or PVG-strict Extent Allocation
-s y
Strict allocation (default)
-s n
-s g
Nonstrict allocation
PVG-strict allocation
-C y
-C n
-d p
Contiguous or Noncontiguous Extent Allocation
Contiguous allocation
Noncontiguous allocation (default)
Mirror Scheduling Policy
Parallel scheduling (default)
-d s
-M y
Sequential scheduling
Mirror Consistency Policy
MWC enable (default, optimal mirror resynchronization during crash recovery)
-M n -c y
MCR enable (full mirror resynchronization during crash recovery)
-M n -c n
MCR disable (no mirror resynchronization during crash recovery)
For example, to create a 240 MB mirrored logical volume with one mirror copy, nonstrict allocation, parallel scheduling, and no mirror resynchronization, enter the following command:
# lvcreate -m 1 -s n -d p -M n -c n -L 240 -n lvol1 /dev/vg01
TIP: To change the characteristics of an existing mirrored logical volume, use the lvchange command. It supports the -C, -c, -d, -M, and -s options. For more information, see lvchange(1M).
Extending a Logical Volume
NOTE: Adding space to a logical volume does not automatically assign that space to the entity using that logical volume. For example, if you want to add space to a file system contained in a logical volume, you must run extendfs after extending the logical volume. See
File System Logical Volumes” (page 97)
and
“Administering Swap Logical Volumes” (page 101)
for more information.
1.
Decide how much more disk space the logical volume needs.
For example, you can add 200 MB of swap space, or an existing project might need an additional 1 GB.
2.
Find out if any space is available using the vgdisplay command. For example:
# vgdisplay vg00
--- Volume groups ---
VG Name /dev/vg00
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 8
Open LV 8
Max PV 16
Cur PV 1
Common LVM Tasks 53
Act PV 1
Max PE per PV 2000
VGDA 2
PE Size (Mbytes) 4
Total PE 249
Alloc PE 170
Free PE 79
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 1.0
VG Max Size 1082g
VG Max Extents 69248
The Free PE entry indicates the number of 4 MB extents available, in this case, 79 (316
MB).
3.
Extend the logical volume. For example:
# lvextend -L 332 /dev/vg00/lvol7
This increases the size of this volume to 332 MB.
NOTE: On the HP-UX 11i v3 March 2010 Update, the size of a logical volume cannot be extended if it has snapshots associated with it. With the HP–UX 11i v3 September 2010 Update, this limitation is removed; and logical volumes with snapshots can be extended.. For information about snapshot logical volumes, see
“Creating and Administering Snapshot Logical Volumes”
.
Extending a Logical Volume to a Specific Disk
For performance reasons, you can force a logical volume to span disks. For example, if you want to create a 30 GB logical volume and put 10 GB on the first disk, another 10 GB on the second disk, and 10 GB on the third disk, then assuming that the extent size is 4 MB, the logical volume requires a total of 7680 extents. To extend the logical volume, follow these steps:
1.
After making the disks physical volumes and creating your volume group, create a logical volume named lvol1 of size 0. For example:
# lvcreate -n lvol1 /dev/vg01
2.
Allocate a third of the extents to the logical volume on the first physical volume. For example:
# lvextend -l 2560 /dev/vg01/lvol1 /dev/disk/disk7
3.
Increase the total number of physical extents allocated to the logical volume for the remaining physical volumes by 2560. In each case, the additional 2560 extents are allocated to the disk specified. For example:
# lvextend -l 5120 /dev/vg01/lvol1 /dev/disk/disk8
# lvextend -l 7680 /dev/vg01/lvol1 /dev/disk/disk9
When you use the -l option with lvextend, you specify space in logical extents.
For another example, you have two disks in a volume group, both identical models. You currently have a 24 GB logical volume that resides on only one of the disks. You want to extend the logical volume size to 40 GB and ensure that the 16 GB increase is allocated to the other disk.
Extend the logical volume to a specific disk as follows:
# lvextend -L 40960 /dev/vg01/lvol2 /dev/disk/disk3
Here, when you use the -L option (uppercase), you specify space in megabytes, not logical extents.
For complete information on command options, see lvextend(1M).
54 Administering LVM
Reducing a Logical Volume
CAUTION: Before you reduce a logical volume, you must notify the users of that logical volume.
For example, before reducing a logical volume that contains a file system, back up the file system.
Even if the file system currently occupies less space than the new (reduced) size of the logical volume, you will almost certainly lose data when you reduce the logical volume. See
File System Logical Volumes” (page 97)
and
“Administering Swap Logical Volumes” (page 101)
for the appropriate procedures for file systems and swap devices.
To reduce a logical volume, follow these steps:
1.
To find out what applications are using the logical volume, use the fuser command. For example:
# fuser -cu /dev/vg01/lvol5
If the logical volume is in use, ensure the underlying applications can handle the size reduction.
You might have to stop the applications.
2.
Decide on the new size of the logical volume.
For example, if the logical volume is mounted to a file system, the new size must be greater than the space the data in the file system currently occupies. The bdf command shows the size of all mounted volumes. The first column shows the space allocated to the volume; the second shows how much is actually being used. The new size of the logical volume must be larger than the size shown in the second column of the bdf output.
3.
Reduce the size of the logical volume as follows:
# lvreduce -L 500 /dev/vg01/lvol5
This command reduces the logical volume/dev/vg01/lvol5 to 500 MB.
NOTE: On the HP-UX 11i v3 March 2010 Update, the size of a logical volume cannot be reduced if it has any type of snapshots associated with it. With the HP-UX 11i v3 September 2010 Update, only logical volumes with associated space efficient snapshots cannot be reduced. For information about snapshots, see
“Creating and Administering Snapshot Logical Volumes” (page 103) .
Adding a Mirror to a Logical Volume
NOTE: Mirroring requires the optional product HP MirrorDisk/UX.
TIP: This task is easier to perform with HP SMH. HP SMH confirms that enough disk space is available for the mirror copy and that the available space meets any allocation policy.
To add a mirror to a logical volume, follow these steps:
1.
Decide how many mirror copies to create.
For this example, you will create one mirror; that is, you will keep two copies of the data online, the original and one mirror copy.
2.
Make sure that there is enough free space in the volume group that contains the logical volume you want to mirror.
The volume group needs at least as much free space as the logical volume you want to mirror currently has allocated to it—that is, you will double the amount of physical space this volume requires.
To use strict mirroring (which HP recommends because it keeps the mirror copy on a separate disk) this free space must be on a disk or disks not currently used by the volume you want to mirror.
Common LVM Tasks 55
3.
Use the lvextend command with the -m option to add the number of additional copies you want. For example:
# lvextend -m 1 /dev/vg00/lvol1
This adds a single mirror copy of the given logical volume.
To force the mirror copy onto a specific physical volume, add it at end of the command line.
For example:
# lvextend -m 1 /dev/vg00/lvol1 /dev/disk/disk4
NOTE: On the HP-UX 11i v3 March 2010 Update, the number of mirror copies of a logical volume cannot be changed if the logical volume has snapshots associated with it. With the
HP-UX 11i v3 September 2010 Update, this limitation has been removed; and logical volumes with associated snapshots can have their mirror count changed. For information about snapshots see
“Creating and Administering Snapshot Logical Volumes” (page 103)
.
Removing a Mirror from a Logical Volume
To remove a mirror copy, use the lvreduce command, specifying the number of mirror copies you want to leave. For example, to remove all mirrors of a logical volume, enter the following command:
# lvreduce -m 0 /dev/vg00/lvol1
This reduces the number of mirror copies to 0, so only the original copy is left.
To remove the mirror copy from a specific disk, use lvreduce and specify the disk from which to remove the mirror copy. For example:
# lvreduce -m 0 /dev/vg00/lvol1 /dev/disk/disk4
NOTE: On the HP-UX 11i v3 March 2010 Update, the number of mirror copies of a logical volume cannot be changed if the logical volume has snapshots associated with it. With the HP-UX
11i v3 September 2010 Update, this limitation has been removed; and logical volumes with associated snapshots can have their mirror count changed. For information about snapshots see
“Creating and Administering Snapshot Logical Volumes” (page 103) .
Renaming a Logical Volume
To change the name of a logical volume, follow these steps:
1.
Make sure that the logical volume has two existing device files, a block device file and a character or raw device file. They must have the same name, except that the character device file name has a leading r. For example, to rename a logical volume in volume group vg00 from lvol1 to database, list the contents of the /dev/vg00 directory. For example:
# cd /dev/vg00
# ls -l total 0 crw-r----- 1 root sys 64 0x000000 Nov 16 02:49 group brw-r----- 1 root sys 64 0x000001 Nov 16 02:49 lvol1 brw-r----- 1 root sys 64 0x000002 Nov 16 02:49 lvol2 brw-r----- 1 root sys 64 0x000003 Nov 16 02:49 lvol3 brw-r----- 1 root sys 64 0x000004 Nov 16 02:49 lvol4 crw-r----- 1 root sys 64 0x000001 Nov 16 02:49 rlvol1 crw-r----- 1 root sys 64 0x000002 Nov 16 02:49 rlvol2 crw-r----- 1 root sys 64 0x000003 Nov 16 02:49 rlvol3 crw-r----- 1 root sys 64 0x000004 Nov 16 02:49 rlvol4
2.
Use the mv command to rename both files. For example:
# mv /dev/vg00/lvol1 /dev/vg00/database
# mv /dev/vg00/rlvol1 /dev/vg00/rdatabase
56 Administering LVM
3.
Update all references to the old name in any other files on the system. These include /etc/ fstab for mounted file systems or swap devices and existing mapfiles from a vgexport command.
Removing a Logical Volume
CAUTION: Removing a logical volume makes its contents unavailable and likely to be overwritten.
In particular, any file system contained in the logical volume is destroyed.
To remove a logical volume, follow these steps:
1.
Make sure that the logical volume is not in use either as a file system or as raw disk space for an application. Use the fuser command as follows:
# fuser -cu /dev/vg01/lvol5
If the logical volume is in use, confirm that the underlying applications no longer need it. You might need to stop the applications.
2.
Use the lvremove command to remove the logical volume. For example:
# lvremove /dev/vg01/lvol5
You can now use this space to extend an existing logical volume or build a new logical volume.
3.
For volume group Version 2.2 and higher, a snapshot and all its predecessors can be removed using a single lvremove command, with the new -F option. See lvremove(1M) for more information.
NOTE: A logical volume with associated snapshots cannot be removed. First, all of its snapshots have to be deleted, then the original logical volume can be deleted.
Exporting a Volume Group
Exporting a volume group removes all data concerning the volume group from the system, while leaving the data on the disks intact. The disks of an exported volume can be physically moved or connected to another system, and the volume group can be imported there.
Exporting a volume group removes information about the volume group and its associated physical volumes from /etc/lvmtab and /etc/lvmtab_p, and removes the volume group's directory with device files in the /dev directory.
1.
Make sure that none of the logical volumes in the volume group are in use. You might need to stop applications using any logical volumes in the volume group, and unmount file systems contained in the volume group.
Use the fuser command on each logical volume. For example:
# fuser -cu /dev/vgnn/lvoln
2.
Deactivate the volume group. For example:
# vgchange -a n vgnn
3.
Use the vgexport command to export the volume group. For example:
# vgexport -v -m /tmp/vgnn.map vgnn
If you are planning to move the volume group to another system, use the -m option to vgexport to create a mapfile. This ASCII file contains the logical volume names because they are not stored on the disks. You must create a mapfile if you do not use the default names
/dev/vgnn/lvoln for the logical volumes in the volume group.
If there are several disks in the volume group, use the -s option with vgexport; this option adds the volume group identifier (VGID) to the mapfile. When the volume group is imported, you can avoid specifying all the disks by name. See
“Importing a Volume Group” (page 58)
.
Common LVM Tasks 57
When vgexport completes, all information about the volume group has been removed from the system. The disks can now be moved to a different system, and the volume group can be imported there.
Importing a Volume Group
To import a volume group, follow these steps:
1.
Connect the disks to the system.
2.
If you are using an HP-UX release before March 2008, or if you want to specify the minor number of the volume group device file, create it using the procedure in
Group Device File” (page 44) .
3.
Use the vgimport command to import the volume group:
# vgimport -v -N -m /tmp/vgnn.map /dev/vgnn list_of_disks
If there are several disks in the volume group and the VGID was saved in the mapfile (that is, the vgexport command was run with the –s and –m options), you can avoid specifying all of them in the vgimport command line by using the -s option. This causes vgimport to scan all the disks on the system. Any physical volumes with a VGID matching the one in the mapfile are included automatically into the volume group.
4.
Activate the volume group as follows:
# vgchange -a y vgnn
NOTE: If the volume group contains any multipathed disks, HP recommends using HP-UX's native multipathing that is a superset of LVM's alternate links. See
“Increasing Hardware Path Redundancy
Through Multipathing” (page 28)
for more information.
If you want to use LVM's alternate link features, importing the volume group has several implications:
•
You must omit the -N option to the vgimport command.
•
The vgimport sets the first link found as the primary link for all physical volumes. If the links are not in the desired order after the import, use vgreduce and vgextend on the primary link for each physical volume for which you want to change the primary.
•
The tunable maxfiles must be more than double the number of disks free.
Modifying Volume Group Parameters
When you create a volume group, you set certain characteristics of the volume group. Using the vgmodify command you can adjust some of the volume group parameters without removing and re-creating the volume group or having to move your data. The vgmodify command enables you to alter different parameters for Version 1.0 volume groups and Version 2.x volume groups.
For version 1.0 volume groups, you can use vgmodify to do the following:
•
Detect and handle physical volume size changes.
•
Modify the maximum number of physical extents that can be allocated per physical volume.
•
Modify the maximum number of physical volumes that the volume group can contain.
•
Modify the maximum number of logical volumes that the volume group can contain.
•
Change a disk type from boot to non-boot or vice versa.
•
Handle physical volume LUN expansion. See
“Modifying Physical Volume Characteristics”
for more details
•
Prepare a physical volume for a LUN contraction. See
for more details.
58 Administering LVM
For version 2.x volume groups, you can use vgmodify to do the following:
•
Detect and handle physical volume size changes
•
Modify the maximum volume group size.
•
Handle physical volume LUN expansion. See
“Modifying Physical Volume Characteristics”
for more details
•
Prepare a physical volume for a LUN contraction. See
for more details.
Beginning with the March 2009 Update, the vgmodify command can be run online (volume group activated and applications running) for Version 1.0 and 2.x volume groups. Additionally, for Version 1.0 volume groups, vgmodify can be run with the volume group offline (deactivated).
vgmodify for a Version 1.0 Volume Group
For Version 1.0 volume groups, use the following procedure to adjust the maximum number of PE per PV, the maximum number of PVs in the VG, and the maximum number of LVs in the VG:
1.
Run vgmodify to collect information about the volume group.
Save the output from these three commands:
# vgmodify -o -r vgnn
# vgmodify -v -t vgnn
# vgmodify -v -n -t vgnn
The -o option attempts to optimize the values by making full use of the existing LVM metadata space. The -t option reports the optimized range of settings without renumbering physical extents; the -n option enables renumbering of physical extents.
2.
Based on the information collected in the previous step, choose new values for the volume group parameters.
3.
The new values may increase the size of the volume group reserved area (VGRA) on each physical volume. The VGRA resides in the LVM header, so increasing its size may require moving the first physical extent of any user data on physical volume. Use the pvmove command to move the first physical extent to another location.
4.
Review the values by running vgmodify with the new settings and the -r option.
5.
Deactivate the volume group, if needed.
TIP: Beginning with the March 2009 Update of HP-UX, the volume group can be active when running vgmodify.
6.
Commit the new values by running vgmodify without the -r option.
7.
If needed, activate the volume group. Run the vgdisplay command to verify the settings have been applied.
Example: vgmodify for a Version 1.0 Volume Group
As an example, you expect to add larger disks to the volume group vg32. You want to increase the maximum number of physical extents per physical volume (max_pe) and the maximum number of physical volumes (max_pv). Here are the steps involved:
1.
Run vgmodify to collect information about the volume group.
Save the output from these three commands:
# vgmodify -o -r vg32
Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1016
PE Size (Mbytes) 32
VGRA Size (Kbytes) 176
Common LVM Tasks 59
New configuration requires "max_pes" are increased from 1016 to 6652
The current and new Volume Group parameters differ.
An update to the Volume Group IS required
New Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 6652
PE Size (Mbytes) 32
VGRA Size (Kbytes) 896
Review complete. Volume group not modified
# vgmodify -v -t vg32
Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1016
PE Size (Mbytes) 32
VGRA Size (Kbytes) 176
VGRA space (Kbytes) on Physical Volumes with extents in use:
PV current -n
/dev/rdisk/disk6 896 32768
/dev/rdisk/disk5 896 32768
Summary 896 32768
Volume Group optimized settings (no PEs renumbered): max_pv(-p) max_pe(-e) Disk size (Mb)
2 53756 1720193
3 35836 1146753
...
213 296 9473
255 252 8065
# vgmodify -v -n -t vg32
Volume Group configuration for /dev/vg32 has been saved in
/etc/lvmconf/vg32.conf
Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1016
PE Size (Mbytes) 32
VGRA Size (Kbytes) 176
VGRA space (Kbytes) on Physical Volumes with extents in use:
PV current -n
/dev/rdisk/disk6 896 32768
/dev/rdisk/disk5 896 32768
Summary 896 32768
Physical Extent zero is not free on all PVs. You will not achieve these values until the first extent is made free (see pvmove(1M)) on all the following disks:
/dev/rdisk/disk6
/dev/rdisk/disk5
Volume Group optimized settings (PEs renumbered lower): max_pv(-p) max_pe(-e) Disk size (Mb)
61 65535 2097152
62 65532 2097056
...
252 16048 513568
255 15868 507808
2.
Based on the output of vgmodify -n -t, choose 255 for max_pv and 15868 for max_pe.
3.
Since the new values require physical extent 0 to be free, use pvmove to move it to another location:
# pvmove /dev/disk/disk5:0 /dev/disk/disk5
Transferring logical extents of logical volume "/dev/vg32/lvol2"...
Physical volume "/dev/disk/disk5" has been successfully moved.
60 Administering LVM
Volume Group configuration for /dev/vg32 has been saved in
/etc/lvmconf/vg32.conf
# pvmove /dev/disk/disk6:0 /dev/disk/disk6
Transferring logical extents of logical volume "/dev/vg32/lvol1"...
Physical volume "/dev/disk/disk6" has been successfully moved.
Volume Group configuration for /dev/vg32 has been saved in
/etc/lvmconf/vg32.conf
4.
Preview the changes by using the -r option to vgmodify:
# vgmodify -p 255 -e 15868 -r -n vg32
Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1016
PE Size (Mbytes) 32
VGRA Size (Kbytes) 176
The current and new Volume Group parameters differ.
An update to the Volume Group IS required
New Volume Group settings:
Max LV 255
Max PV 255
Max PE per PV 15868
PE Size (Mbytes) 32
VGRA Size (Kbytes) 32640
Review complete. Volume group not modified
5.
Deactivate the volume group:
# vgchange -a n vg32
Volume group "vg32" has been successfully changed.
6.
Commit the new values:
# vgmodify -p 255 -e 15868 -n vg32
Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1016
PE Size (Mbytes) 32
VGRA Size (Kbytes) 176
The current and new Volume Group parameters differ.
An update to the Volume Group IS required
New Volume Group settings:
Max LV 255
Max PV 255
Max PE per PV 15868
PE Size (Mbytes) 32
VGRA Size (Kbytes) 32640
New Volume Group configuration for "vg32" has been saved in
"/etc/lvmconf/vg32.conf"
Old Volume Group configuration for "vg32" has been saved in
"/etc/lvmconf/vg32.conf.old"
Starting the modification by writing to all Physical Volumes
Applying the configuration to all Physical Volumes from
"/etc/lvmconf/vg32.conf"
Completed the modification process.
New Volume Group configuration for "vg32" has been saved in
"/etc/lvmconf/vg32.conf.old"
Volume group "vg32" has been successfully changed.
7.
Activate the volume group and verify the changes:
# vgchange -a y vg32
Activated volume group
Volume group "vg32" has been successfully changed.
Common LVM Tasks 61
# vgdisplay vg32
--- Volume groups ---
VG Name /dev/vg32
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 0
Open LV 0
Max PV 255
Cur PV 2
Act PV 2
Max PE per PV 15868
VGDA 4
PE Size (Mbytes) 32
Total PE 1084
Alloc PE 0
Free PE 1084
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 1.0
vgmodify for a Version 2.x Volume Group
If the maximum volume group size (chosen when the Version 2.x volume group was created by the vgcreate command) needs to be increased, then the vgmodify -S option can be used to increase the maximum volume group size
For instance, the maximum volume group size might need to be increased to allow more extents to be added to the volume group through the vgextend command or through LUN expansion
(see the vgmodify -E option described in
“Modifying Physical Volume Characteristics” (page 77) ).
The maximum volume group size can also be reduced through the vgmodify -S option to make more extents available on the physical volumes.
Increasing the maximum volume group size might require that additional space be added to every physical volume through LUN expansion. In this case, you can invoke the –E and –S options together to handle the LUN expansions and increase the maximum VG size in a single step.
LVM might also use free extents at the ends of the physical volumes to increase the maximum volume group size. If insufficient free extents are available at the end of some physical volumes, and those physical volume cannot be expanded further via LUN expansion, it might be necessary to free the extents at the ends of those physical volumes by using the pvmove command to relocate the portions of the logical volumes that are using those extents.
When using the vgmodify -S option to increase the maximum volume group size, note that the maximum volume group size is not increased until all physical volumes in the volume group are reconfigured.
When using the vgmodify -S option to decrease the maximum volume group size, note that the maximum volume group size is decreased prior to reconfiguring the physical volumes.
To increase the maximum size of a Version 2.x volume group, follow these steps:
1.
Use the vgmodify review mode to verify that there is enough free space on all of the physical volumes to reconfigure them to the desired larger maximum VG size. The vgmodify command checks for free extents at the ends of the PVs that it can utilize, and also checks for free spaces resulting from prior LUN expansions. You must provide the -E option and the -S option for review mode to check for LUN expansions. It might be necessary to use the pvmove command to relocate the portions of logical volumes residing at the ends of the PVs.
# vgmodify -r -a -E -S 64t vg1
62 Administering LVM
2.
If review mode indicates that the maximum VG size can be increased, perform the actual reprovisioning reconfiguration. This operation reconfigures every PV in the VG to the new
(larger) maximum VG size. This operation also automatically adds new extents to PVs where the new extents were previously not added because the volume group was at its maximum number of extents.
# vgmodify -a -E -S 64t vg1
3.
Verify the result of the reprovisioning reconfiguration by running the vgdisplay -v command to check the new maximum VG size, the new maximum number of extents for the VG, and additional extents that might have been added to some of the PVs..
4.
If any vgextend were previously unable to add PVs to the volume group, rerun those commands now. The vgextend commands must succeed in adding more PVs to the VG. Run vgdisplay -v to verify that more free extents are now available.
5.
Expand logical volumes using lvextend -l as necessary to allow them to accommodate more user data. You can also create additional logical volumes using lvcreate. You can also add additional mirrors using lvextend -m.
To decrease the maximum Volume Group size for a Version 2.x volume group, follow these steps:
1.
Use the review mode of vgmodify to verify that the volume group maximum size can be decreased to the desired lower value.
# vgmodify -r -a -S 32t vg1
2.
If review mode indicates that the maximum VG size can be decreased, perform the actual reprovisioning reconfiguration. The vgmodify command reconfigures every PV in the VG to reduce the amount of space being used for LVM configuration date. The unused space is made available as new extents for user data
# vgmodify -a -S 32t vg1
3.
Verify the result of the reprovisioning reconfiguration by running the vgdisplay -v command to check the new maximum VG size, the new maximum number of extents for the VG, the new total number of extents for the VG, and the new number of free extents for the VG.
Example: vgmodify for a Version 2.x Volume Group
Here is an example of online reprovisioning when a volume group has reached its maximum VG size limit. In this example, the vgmodify -S option is used to increase the maximum VG size for a 2.x volume group that has reached its maximum VG size limit. Here is the scenario:
The volume group /dev/vg1 has two physical volumes, /dev/disk/disk46 and /dev/disk/ disk47
.
The physical volume /dev/disk/disk46 currently has 38398 extents and some extents at the end of the physical volume are free. The physical volume /dev/disk/disk47 currently has
25602 extents. The volume group currently has 64000 extents (38398 + 25602 = 64000).
The maximum VG size as shown by vgdisplay is 500 GB. The maximum number of extents in the volume group is 64000.
The diskinfo command shows that both physical volumes are roughly 300 GB in size. However, since the maximum VG size is only 500 GB, roughly 100 GB is currently unavailable for use on
/dev/disk/disk47
. In addition, any attempt to add more physical volumes through the vgextend command will fail since the volume group is already at its maximum VG size limit.
To make the full 300 GB on /dev/disk/disk47 available for use, and to allow additional physical volumes to be added to the volume group through the vgextend command, the vgmodify
-S option can be used to increase the maximum VG size. In this example, it is increased from 500
GB to 8 TB to allow room for future growth. The steps involved are:
1.
Run vgdisplay, which shows that the maximum VG size is 500 GB and the maximum number of extents in the volume group (determined from the maximum VG size) is 64000.
Common LVM Tasks 63
# vgdisplay -v vg1
--- Volume groups ---
VG Name /dev/vg1
...
VG Version 2.1
VG Max Size 500 GB
VG Max Entents 64000
...
2.
Run diskinfo on the physical volumes to display their size.
# diskinfo /dev/rdisk/disk46
# diskinfo /dev/rdisk/disk47
3.
Run online vgmodify in review mode to verify that all physical volumes can be reconfigured to the new (larger) maximum VG size of 8TB.
# vgmodify -r -a -E -S 8t vg1
Physical volume "/dev/disk/disk46" requires reconfiguration to be provisioned to the requested maximum volume group size 8388608 MB.
Current number of extents: 38398
Number of extents after reconfiguration: 38396
...
Physical volume "/dev/disk/disk46" was not changed.
Physical volume "/dev/disk/disk4" requires reconfiguration to be provisioned to the requested maximum volume group size 8388608 MB.
Current number of extents: 25602
Number of extents after reconfiguration: 25602
...
Physical volume "/dev/disk/disk47" was not changed.
In this example, all physical volumes in the volume group can be reconfigured, so the maximum
Volume Group size of /dev/vg1 can be increased from 500 GB to 8 TB.
Note that two free extents will be used for the reconfiguration on /dev/disk/disk46, reducing the extents on that physical volume from 38398 to 39396.
4.
Note that additional extents will be added to /dev/disk/disk47 when the vgmodify -S option is run in change mode, as shown here.
# vgmodify -a -E -S 8t vg1
Reconfiguration of physical volume "/dev/disk/disk46" for the requested maximum volume group size 8388608 MB succeeded.
Previous number of extents: 38398
Number of extents after reconfiguration: 38396
Physical volume "/dev/disk/disk46" was changed.
Volume Group configuration for /dev/vg1 has been saved in
/etc/lvmconf/vg1.conf
Reconfiguration of physical volume "/dev/disk/disk47" for the requested maximum volume group size 8388608 MB succeeded.
Previous number of extents: 25604
Number of extents after reconfiguration: 25604
Physical volume "/dev/disk/disk47" was changed.
The maximum volume group size for "/dev/vg1" has been increased from 512000 MB to 8388608 MB.
Volume Group configuration for /dev/vg1 has been saved in
/etc/lvmconf/vg1.conf
As noted for review mode, two extents were taken from /dev/disk/disk46 for the reconfiguration (a decrease from 38398 to 38396). This allowed two extents to be added to
/dev/disk/disk47
(an increase from 25602 to 25604) before the maximum volume group size was increased
64 Administering LVM
5.
Note that the number of extents for /dev/disk/disk47 is increased from 25604 to 38396 after the maximum VG size is increased, as shown by vgdisplay -v here. This command confirms that the maximum VG size was increased from 500 GB to 8 TB, and that the number of extents for /dev/disk/disk47 was increased from 25602 extents to 38396 extents, as shown by the vgdisplay command below.
# vgdisplay –v vg1
--- Volume groups ---
VG Name /dev/vg1
...
PE Size (Mbytes) 8
Total PE 76792
Alloc PE 51196
Free PE 25596
...
VG Version 2.1
VG Max Size 8t
VG Max Extents 1048576
--- Logical volumes ---
LV Name /dev/vg1/lvol1
LV Status available/syncd
LV Size (Mbytes) 204784
Current LE 25598
Allocated PE 51196
Used PV 2
--- Physical volumes ---
PV Name /dev/disk/disk46
PV Status available
Total PE 38396
Free PE 12798
...
PV Name /dev/disk/disk47
PV Status available
Total PE 38396
Free PE 12798
Quiescing and Resuming a Volume Group
If you plan to use a disk management utility to create a backup image or “snapshot” of all the disks in a volume group, you must make sure that LVM is not writing to any of the disks when the snapshot is being taken; otherwise, some disks can contain partially written or inconsistent LVM metadata. To keep the volume group disk image in a consistent state, you must either deactivate the volume group or quiesce it.
Deactivating the volume group requires you to close all the logical volumes in the volume group, which can be disruptive. For example, you must unmount any file system using a logical volume in the volume group. However, temporarily quiescing the volume group enables you to keep the volume group activated and the logical volumes open during the snapshot operation, minimizing the impact to your system.
You can quiesce both read and write operations to the volume group, or just write operations.
While a volume group is quiesced, the vgdisplay command reports the volume group access mode as quiesced. The indicated I/O operations queue until the volume group is resumed, and commands that modify the volume group configuration fail immediately.
Common LVM Tasks 65
NOTE: Individual physical volumes or logical volumes cannot be quiesced using this feature. To temporarily quiesce a physical volume to disable or replace it, see
“Disabling a Path to a Physical
Volume” (page 87) . To quiesce a logical volume, quiesce or deactivate the volume group. To
provide a stable image of a logical volume without deactivating the volume group, mirror the logical volume, then split off one of the mirrors, as described in
“Backing Up a Mirrored Logical
Quiescing a volume group is not persistent across reboots.
To quiesce a volume group, use the vgchange command with the -Q option as follows:
# vgchange -Q mode vgnn
The mode parameter can be either rw, which blocks both read and write operations, or w, which permits read operations but blocks write operations.
By default, the volume group remains quiesced until it is explicitly resumed. You can specify a maximum quiesce time in seconds using the -t option. If the quiesce time expires, the volume group is resumed automatically. For example, to quiesce volume group vg08 for a maximum of ten minutes (600 seconds) but permitting read operations, enter the following command:
# vgchange -Q w -t 600 vg08
To resume a quiesced volume group, use the vgchange command with the -R option as follows:
# vgchange -R vgnn
Renaming a Volume Group
To change the name of a volume group, export it, then import it using the new name. For more detailed information on how to export and import a volume group, see
and
“Importing a Volume Group” (page 58)
.
To rename the volume group vg01 to vgdb, follow these steps:
1.
Deactivate the volume group as follows:
# vgchange -a n vg01
2.
If you want to retain the same minor number for the volume group, examine the volume group's group file as follows:
# ls -l /dev/vg01/group crw-r--r-- 1 root sys 64 0x010000 Mar 28 2004 /dev/vg01/group
For this example, the volume group major number is 64, and the minor number is 0x010000.
3.
Export the volume group as follows:
# vgexport -m vg01.map vg01
4.
If you are using an HP-UX release before March 2008, or if you want to specify the minor number of the volume group device file, create it for the volume group's new name, using the procedure in
“Creating the Volume Group Device File” (page 44)
.
Since the group file in this example has a major number of 64 and a minor number of
0x010000, enter the following commands:
# mkdir /dev/vgdb
# mknod /dev/vgdb/group c 64 0x010000
5.
Import the volume group under its new name as follows:
# vgimport -m vg01.map /dev/vgdb
6.
Back up the volume group configuration information as follows:
# vgcfgbackup /dev/vgdb
7.
Activate the volume group as follows:
# vgchange -a y /dev/vgdb
8.
Remove saved configuration information based on the old volume group name as follows:
66 Administering LVM
# rm /etc/lvmconf/vg01.conf
Note: if your volume group is Version 2.x and does not have any bootable physical volumes, and if you have configured a new path for the configuration file using the
LVMP_CONF_PATH_NON_BOOT variable in the /etc/lvmrc file, you need to remove the configuration file from the new path.
9.
Update all references to the old name in any other files on the system. These include /etc/ fstab for mounted file systems or swap devices, and existing mapfiles from a vgexport command.
Splitting a Volume Group
You can use the vgchgid to split an existing volume group into two or more volume groups, provided that the physical volumes to be split are self-contained; that is, any logical volumes on the physical volumes must be wholly contained on those physical volumes. For example, a splittable volume group can have logical volumes 1, 2, and 3 on physical volumes 0 and 1, and logical volumes 4, 5, and 6 on physical volumes 2, 3, 4, and 5.
In this example, volume group vgold contains physical volumes /dev/disk/disk0 through
/dev/disk/disk5
. Logical volumes lvol1, lvol2, and lvol3 are on physical volumes /dev/ disk/disk0 and /dev/disk/disk1, and logical volumes lvol4, lvol5, and lvol6 are on the remaining physical volumes.
To keep /dev/disk/disk0 and /dev/disk/disk1 in vgold and split the remaining physical volumes into a new volume group named vgnew, follow these steps:
1.
Deactivate the volume group as follows:
# vgchange -a n vgold
2.
Export the volume group as follows:
# vgexport vgold
3.
Change the VGID on the physical volumes to be assigned to the new volume group as follows:
# vgchgid -f /dev/rdisk/disk2 /dev/rdisk/disk3 \
/dev/rdisk/disk4 /dev/rdisk/disk5
4.
If you are using an HP-UX release before March 2008, or if you want to specify the minor number of the vgold group file, create it using the procedure in
.
5.
If you are using an HP-UX release before March 2008, or if you want to specify the minor number of the vgnew group file, create it using the procedure in
.
6.
Import the physical volumes in the old volume group as follows:
# vgimport /dev/vgold /dev/rdisk/disk0 /dev/rdisk/disk1
7.
Import the physical volumes in the new volume group as follows:
# vgimport /dev/vgnew /dev/rdisk/disk2 /dev/rdisk/disk3 \
/dev/rdisk/disk4 /dev/rdisk/disk5
8.
Activate the volume groups. Disable quorum checks for the old volume group (it is missing over half its disks) as follows:
# vgchange -a y -q n /dev/vgold
# vgchange -a y /dev/vgnew
9.
The logical volumes are currently defined in both volume groups. Remove the duplicate logical volumes from the volume group that no longer contains them as follows:
# lvremove -f vgold/lvol4 vgold/lvol5 vgold/lvol6
# lvremove -f vgnew/lvol1 vgnew/lvol2 vgnew/lvol3
10. The physical volumes are currently defined in both volume groups. Remove the missing physical volumes from both volume groups as follows:
Common LVM Tasks 67
# vgreduce -f vgold
# vgreduce -f vgnew
11. Enable quorum checks for the old volume group as follows:
# vgchange -a y -q y /dev/vgold
On completion, the original volume group contains three logical volumes (lvol1, lvol2, and lvol3
) with physical volumes /dev/disk/disk0 and /dev/disk/disk1. The new volume group vgnew contains three logical volumes (lvol4, lvol5, and lvol6) across physical volumes
/dev/disk/disk2
, /dev/disk/disk3, /dev/disk/disk4, and /dev/disk/disk5.
Removing a Volume Group
TIP: It is easier to export a volume group than to remove it, because removing the volume group requires that you remove all the logical volumes and physical volumes from the volume group before running vgremove. In addition, exporting the volume group leaves the LVM information on the disks untouched, which is an advantage if you want to reimport the volume group later. For the procedure to export a volume group, see
“Exporting a Volume Group” (page 57)
.
To remove a volume group, follow these steps:
1.
Back up all user data.
2.
Find the names of all logical volumes and physical volumes in the volume group. Enter the following command:
# vgdisplay -v /dev/vgnn
3.
Make sure that none of those logical volumes are in use. This may require stopping applications using any logical volumes in the volume group, and unmounting file systems contained in the volume group.
Use the fuser command on each logical volume:
# fuser -cu /dev/vgnn/lvoln
4.
Remove each of the logical volumes as follows:
# lvremove /dev/vgnn/lvoln
For more information, see
“Removing a Logical Volume” (page 57)
.
5.
Remove all but one of the physical volumes as follows:
# vgreduce /dev/vgnn /dev/disk/diskn
For more information, see
“Removing a Disk from a Volume Group” (page 51) .
6.
Use the vgremove command to remove the volume group as follows:
# vgremove vgnn
Backing Up a Mirrored Logical Volume
NOTE: Mirroring requires the optional product HP MirrorDisk/UX.
You can split a mirrored logical volume into two logical volumes to perform a backup on an offline copy while the other copy stays online. When you complete the backup of the offline copy, you can merge the two logical volumes back into one. To bring the two copies back in synchronization,
LVM updates the physical extents in the offline copy based on changes made to the copy that remained in use.
You can use HP SMH to split and merge logical volumes, or use the lvsplit and lvmerge commands.
To back up a mirrored logical volume containing a file system, using lvsplit and lvmerge, follow these steps:
68 Administering LVM
1.
Split the logical volume /dev/vg00/lvol1 into two separate logical volumes as follows:
# lvsplit /dev/vg00/lvol1
This creates the new logical volume /dev/vg00/lvol1b. The original logical volume /dev/ vg00/lvol1 remains online.
2.
Perform a file system consistency check on the logical volume to be backed up as follows:
# fsck /dev/vg00/lvol1b
3.
Mount the file system as follows:
# mkdir /backup_dir
# mount /dev/vg00/lvol1b /backup_dir
4.
Perform the backup using the utility of your choice.
5.
Unmount the file system as follows:
# umount /backup_dir
6.
Merge the split logical volume back with the original logical volume as follows:
# lvmerge /dev/vg00/lvol1b /dev/vg00/lvol1
NOTE: lvsplit is not supported on snapshot logical volumes. lvmerge is not supported for snapshots as well as logical volumes having snapshots.
Backing Up and Restoring Volume Group Configuration
It is important that volume group configuration information be saved whenever you make any change to the configuration such as:
•
Adding or removing disks to a volume group
•
Changing the disks in a root volume group
•
Creating or removing logical volumes
•
Extending or reducing logical volumes
Unlike fixed disk partitions or nonpartitioned disks that begin and end at known locations on a given disk, each volume group configuration is unique, changes, and uses space on several disks.
If you back up your volume group configuration, you can restore a corrupted or lost LVM configuration in the event of a disk failure or corruption of your LVM configuration information.
The vgcfgbackup command creates or updates a backup file containing the volume group configuration; it does not back up the data within your logical volumes. To simplify the backup process, vgcfgbackup is invoked automatically whenever you make a configuration change as a result of using any of the following commands: lvchange lvreduce pvchange lvcreate lvremove pvmove lvextend lvrmboot vgchange
1 lvlnboot lvsplit vgextend lvmerge vgcreate vgmodify vgreduce
1 For volume group Version 2.2 and higher, the vgchange command automatically takes a backup of the volume group configuration during deactivation, provided they are not activated in read-only mode. In all earlier versions, there is no automatic backup when vgchange is used.
When snapshots are involved, the volume group configuration changes with respect to the snapshot data unsharing while writes are occurring on the snapshot tree. So, it is recommended that the automatic backup of the volume group configuration not be overridden by the —A n option during volume group deactivation.
You can display LVM configuration information previously backed up with vgcfgbackup or restore it using vgcfgrestore.
Common LVM Tasks 69
By default, vgcfgbackup saves the configuration of a volume group to the file
volume_group_name.conf
in the default directory /etc/lvmconf/. You can override this default directory setting for volume group Version 2.x by configuring a new path in the
LVMP_CONF_PATH_NON_BOOT variable in the /etc/lvmrc file. For more information see
vgcfgbackup(1M)
NOTE: After a cold installation of the HP-UX 11i v3 March 2010 release, the /etc/lvmrc file will contain the LVMP_CONF_PATH_NON_BOOT variable definition as below:
LVMP_CONF_PATH_NON_BOOT=""
But if you have upgraded your system from earlier version to HP-UX 11i v3 March 2010, this default definition will not exist. In such case, you can manually define the variable in /etc/lvmrc to configure a new path.
You can also run vgcfgbackup at the command line, saving the backup file in any directory you indicate. If you do, first run vgdisplay with the -v option to ensure that the all logical volumes in the volume group are shown as available/syncd. If so, then run the following command:
# vgcfgbackup -f pathname/filename volume_group_name
If you use the -f option with vgcfgbackup to save the configuration file in a non-default location, take note of and retain its location. For information on command options, see vgcfgbackup(1M).
Make sure backups of the root volume group are on the root file system, in case these are required during recovery.
To run vgcfgrestore, the physical volume must be detached. If all the data on the physical volume is mirrored and the mirror copies are current and available, you can temporarily detach the physical volume using pvchange, perform the vgcfgrestore, and reattach the physical volume. For example, to restore volume group configuration data for /dev/disk/disk5, a disk in the volume group /dev/vgsales, enter the following commands:
# pvchange -a n /dev/disk/disk5
# vgcfgrestore -n /dev/vgsales /dev/rdisk/disk5
# pvchange -a y /dev/disk/disk5
If the physical volume is not mirrored or the mirror copies are not current and available, you must deactivate the volume group with vgchange, perform the vgcfgrestore, and activate the volume group as follows:
# vgchange -a n /dev/vgsales
# vgcfgrestore -n /dev/vgsales /dev/rdisk/disk5
# vgchange -a y /dev/vgsales
These examples restore the LVM configuration to the disk from the default backup location in /etc/ lvmconf/vgsales.conf
.
For information on command options, see vgcfgrestore(1M).
Moving and Reconfiguring Your Disks
This section addresses the following topics:
•
“Moving Disks Within a System” (page 71)
•
“Moving Disks Between Systems” (page 72)
•
“Moving Data to a Different Physical Volume” (page 73)
•
“Modifying Physical Volume Characteristics” (page 77)
•
“Disabling a Path to a Physical Volume” (page 87)
•
“Creating an Alternate Boot Disk” (page 88)
•
“Mirroring the Boot Disk” (page 90)
70 Administering LVM
•
“Mirroring the Boot Disk on HP 9000 Servers” (page 90)
•
“Mirroring the Boot Disk on HP Integrity Servers” (page 92)
You might need to do the following tasks:
•
Move the disks in a volume group to different hardware locations on a system.
•
Move entire volume groups of disks from one system to another.
CAUTION: Moving a disk that is part of your root volume group is not recommended. For more information, see Configuring HP-UX for Peripherals.
The /etc/lvmtab and /etc/lvmtab_p files contain information about the mapping of LVM disks on a system to volume groups; that is, volume group names and lists of the physical volumes included in volume groups. When you do either of the previous tasks, these configuration files must be changed to reflect the new hardware locations and device files for the disks. However, you cannot edit these files directly because they are not text files. Instead, you must use vgexport and vgimport to reconfigure the volume groups, which records configuration changes in the LVM configuration files.
Moving Disks Within a System
There a two procedures for moving the disks in a volume group to different hardware locations on a system. Choose a procedure depending on whether you use persistent or legacy device files for your physical volumes; the types of device files are described in
Persistent Device Files” (page 12) .
LVM Configuration with Persistent Device Files
If your LVM configuration uses persistent device files, follow these steps:
1.
Be sure that you have an up-to-date backup for both the data within the volume group and the volume group configuration.
2.
Deactivate the volume group by entering the following command:
# vgchange -a n /dev/vgnn
3.
Physically move your disks to their desired new locations.
4.
Activate the volume group as follows:
# vgchange -a y /dev/vgnn
LVM Configuration with Legacy Device Files
The names of legacy device files change when the hardware paths to their physical devices change.
Therefore, you must update the LVM configuration by exporting and importing the volume group to use the new legacy device files. Follow these steps:
1.
Be sure that you have an up-to-date backup for both the data within the volume group and the volume group configuration.
2.
Deactivate the volume group as follows:
# vgchange -a n /dev/vgnn
3.
If you want to retain the same minor number for the volume group, examine the volume group's group file as follows:
# ls -l /dev/vgnn/group crw-r--r-- 1 root sys 64 0x010000 Mar 28 2004 /dev/vgnn/group
For this example, the volume group major number is 64, and the minor number is 0x010000.
4.
Remove the volume group device files and its entry from the LVM configuration files by entering the following command:
# vgexport -v -s -m /tmp/vgnn.map /dev/vgnn
Moving and Reconfiguring Your Disks 71
5.
Physically move your disks to their desired new locations.
6.
To view the new locations, enter the following command:
# vgscan -v
7.
If you are using an HP-UX release before March 2008, or if you want to retain the minor number of the volume group device file, create it using the procedure in
Group Device File” (page 44) .
Since the group file in this example has a major number of 64 and a minor number of
0x01000000, enter the following commands:
# mkdir /dev/vgnn
# mknod /dev/vgnn/group c 64 0x010000
8.
Add the volume group entry back to the LVM configuration files using the vgimport command as follows:
# vgimport -v -s -m /tmp/vgnn.map /dev/vgnn
9.
Activate the newly imported volume group as follows:
# vgchange -a y /dev/vgnn
10. Back up the volume group configuration as follows:
# vgcfgbackup /dev/vgnn
Moving Disks Between Systems
To move the disks in a volume group to different hardware locations on a different system, export the volume group from one system, physically move the disks to the other system, and import the volume group there. The procedures for exporting and importing a volume are described in
“Exporting a Volume Group” (page 57)
and
“Importing a Volume Group” (page 58)
. They are illustrated in the following example.
NOTE: If the volume group contains any multipathed disks, see the note under
To move the three disks in the volume group /dev/vg_planning to another system, follow these steps:
1.
If any of the logical volumes contain a file system, unmount the file system. If any of the logical volumes are used as secondary swap, disable swap and reboot the system; for information on secondary swap, see HP-UX System Administrator's Guide: Configuration Management.
2.
Make the volume group and its associated logical volumes unavailable to users as follows:
# vgchange -a n /dev/vg_planning
3.
Preview the removal of the volume group information from the LVM configuration files using the following command:
# vgexport -p -v -s -m /tmp/vg_planning.map /dev/vg_planning
With the -m option, you can specify the name of a map file that will hold the information that is removed from the LVM configuration files. The map file contains the names of all logical volumes in the volume group. You use this map file when you set up the volume group on the new system.
4.
If the preview is satisfactory, remove the volume group information as follows:
# vgexport -v -s -m /tmp/vg_planning.map /dev/vg_planning
The vgexport command removes the volume group from the system and creates the /tmp/ vg_planning.map
file.
5.
Connect the disks to the new system and copy the /tmp/vg_planning.map file to the new system.
72 Administering LVM
6.
If you are using an HP-UX release before March 2008, create the volume group device file using the procedure in
“Creating the Volume Group Device File” (page 44) .
7.
To get device file information about the disks, run the ioscan command:
# ioscan -funN -C disk
8.
To preview the import operation, run the vgimport command with the -p option:
# vgimport -p -N -v -s -m /tmp/vg_planning.map /dev/vg_planning
9.
To import the volume group, run vgimport without the -p option as follows:
# vgimport -N -v -s -m /tmp/vg_planning.map /dev/vg_planning
10. Activate the newly imported volume group as follows:
# vgchange -a y /dev/vg_planning
Moving Data to a Different Physical Volume
You can use the pvmove command to move data contained in logical volumes from one disk to another disk or to move data between disks within a volume group.
For example, you can move the data from a specific logical volume from one disk to another, to use the vacated space on the first disk for another purpose. To move the data in logical volume
/dev/vg01/markets from the disk /dev/disk/disk4 to the disk /dev/disk/disk7, enter the following:
# pvmove -n /dev/vg01/markets /dev/disk/disk4 /dev/disk/disk7
On the other hand, you can move all the data contained on one disk, regardless of which logical volume it is associated with, to another disk within the same volume group. For example, do this to remove a disk from a volume group. You can use pvmove to move the data to other specified disks or let LVM move the data to appropriate available space within the volume group, subject to any mirroring allocation policies.
To move all data off disk /dev/dsk/disk3 and relocate it at the destination disk /dev/disk/ disk5
, enter the following command:
# pvmove /dev/disk/disk3 /dev/disk/disk5
To move all data off disk /dev/disk/disk3 and let LVM transfer the data to available space within the volume group, enter the following command:
# pvmove /dev/disk/disk3
In each of the previous instances, if space does not exist on the destination disk, the pvmove command fails. The pvmove also provides a-p option for you to preview the operation before actually performing the move.
Moving a Root Disk to Another Disk
If the data to be moved is the root disk, additional steps are required. Use the following steps on an HP 9000 system as an example, to move root disk /dev/disk/disk1 (source disk) to disk
/dev/disk/disk4
(destination disk) staying within the same volume group:
1.
To make the destination disk a bootable LVM disk, enter:
# pvcreate -B /dev/rdisk/disk4
2.
To make the disk bootable. Enter:
# mkboot /dev/rdisk/disk4
# mkboot -a "hpux -a (;0)/stand/vmunix" /dev/rdisk/disk4
3.
To extend your root volume group with the destination disk, enter:
# vgextend /dev/vg00 /dev/disk/disk4
4.
To move all physical extents from the source disk to the destination disk, enter:
# pvmove /dev/disk/disk1 /dev/disk/disk4
Moving and Reconfiguring Your Disks 73
5.
To reduce the source disk from the volume group, enter:
# vgreduce /dev/vg00 /dev/disk/disk1
6.
To shut down and reboot from the new root disk in maintenance mode, enter:
ISL> hpux -lm (;0)/stand/vmunix
7.
In maintenance mode, to update the BDRA and the LABEL file, enter:
# vgchange -a y /dev/vg00
# lvlnboot -b /dev/vg00/lvol1
# lvlnboot -s /dev/vg00/lvol2
# lvlnboot -r /dev/vg00/lvol3
# lvlnboot -Rv
# vgchange -a n /dev/vg00
8.
Reboot the system normally.
pvmove Command Syntax
Beginning with the September 2008 Update, pvmove provides these options:
-p Provides a preview of the move but does not actually perform the move.
-e no_of_extents Moves the last number of physical extents, specified by
no_of_extents
.
de
se1 [-se2]
Specifies the starting location of the destination physical extents within a destination physical volume.
Defines the source physical extent range, provided along with source physical volume.
Beginning with the September 2009 Update, pvmove additionally provides these options:
-a Moves data to achieve auto-rebalance of disk space usage within a volume group. Supported for Version 2.x volume groups only. See
Disk Space Balancing: Auto Re-balancing” (page 75)
.
-f pv_path
-s
Moves data from the specified physical path, pv_path, to remaining physical volumes to achieve balance. Supported only with the -a option.
Provides a summary preview report of the data move, but does not actually move data. Used only with the -a and -p options for a preview of data auto-rebalance.
See the pvmove(1M) manpage for details on all its options.
74 Administering LVM
NOTE: The pvmove command is not an atomic operation; it moves data extent by extent. The following might happen upon abnormal pvmove termination by a system crash or kill -9:
For Version 1.0 volume groups prior to the September 2009 Update, the volume group can be left in an inconsistent configuration showing an additional pseudomirror copy for the extents being moved. You can remove the extra mirror copy using the lvreduce command with the –m option on each of the affected logical volumes; there is no need to specify a disk.
For version 1.0 with September 2009 Update or Version 2.0 volume groups: On abnormal termination, the contiguous LV in question might have its extents laid out in a non-contiguous manner. If so, it is recommended that you run lvdisplay -v to check if the allocation policy for the LV is broken. If it is broken, then run the steps below to make contiguous the extents of this LV:
1.
Change the allocation policy of this LV to default (see lvchange(1M)).
2.
Move the extents such that all the physical extents of the logical volume are contiguous (see
pvmove(1M)).
3.
Change the allocation policy back to contiguous (see lvchange(1M).)
Moving Data for Disk Space Balancing: Auto Re-balancing
Definition
In this section, “balancing” refers to maintaining the percentage of free and used space on each involved physical volume equal to the total percentage of free and used space on all the physical volumes that are selected in the balance operation; calculations are based upon the number of physical extents. Auto re-balancing refers to the automatic movement of extents based on the optimal number of extents calculated automatically for each logical volume on each physical volume involved in the re-balance operation. Beginning with the September 2009 Update of HP-UX, you can achieve automatic re-balancing on Version 2.x volume groups using the –a option of the pvmove command.
Purpose
Balancing achieves better space utilization for existing storage, especially after physical volumes have been recently added or deleted. Additionally, balancing can give better I/O performance for the target logical volumes.
Usage
There are three different ways to use the –a option:
• pvmove –a vg_name all logical volumes within the volume group vg_name are auto re-balanced
• pvmove –a lv_path [pv_path | pvg_name] only the logical volumes specified by lv_path are auto re-balanced. They are balanced across all the physical volumes within the volume group or the optional targets specified by the physical volume pv_path or physical volume group pvg_name
• pvmove –a –f pv_path all extents are moved from the physical volume pv_path to the remaining physical volumes within the volume group; then, all logical volumes are re-balanced across those same remaining physical volumes. You can use this when you want to remove or replace the physical volume specified by pv_path.
Preview Mode
Before performing a pvmove for balancing, you can run a preview of the operation using the –p option. In addition, the –s option can be used to generate a preview summary report of the requested re-balance without actually performing any move. The –s option is only valid with the
–p and–a options. See the pvmove(1M) manpage for more details on the pvmove features.
Moving and Reconfiguring Your Disks 75
Example
Consider a volume group having the configuration below:
•
Three physical volumes each of size 1245 extents:
/dev/disk/disk10
, /dev/disk/disk11, and /dev/disk/disk12.
•
Three logical volumes all residing on same disk, /dev/disk/disk10:
/dev/vg_01/lvol1
(Size = 200 extents),
/dev/vg_01/lvol2
(Size = 300 extents),
/dev/vg_01/lvol3
(Size = 700 extents).
The pvmove below generates a summary report to preview the re-balance of volume group vg_01:
# pvmove -p -s -a vg_01
--- Summary Report of re-balance operation ---
The optimal percentage of free space per PV = 68%
The optimal percentage of used space per PV = 32%
--- Before re-balance operation ---
The average percentage of free space on each PV =~ (68 +/- 32)%
The average percentage of used space on each PV =~ (32 +/- 32)%
--- After re-balance operation ---
The average percentage of free space on each PV =~ (68 +/- 0)%
The average percentage of used space on each PV =~ (32 +/- 0)%
The output above is interpreted as follows:
•
The average percentage free space on each PV, before re-balance operation, is approximately in the range of (68 - 32 =) 36% to (68 + 32 = ) 100% and after re-balance operation would be approximately (68 +/- 0 =) 68%.
•
The average percentage used space on each PV, before re-balance operation, is approximately in the range of (32 - 32 = ) 0% to (32 + 32 =) 64% and after re-balance operation would be approximately (32 +/- 0 =) 32%.
The pvmove command below actually moves the data for balancing:
# pvmove -a vg_01
Automatic re-balance operation successfully completed.
Volume Group configuration for /dev/vg_01 has been saved in
/etc/lvmconf/vg_01.conf
NOTE: In the automatic re-balance mode, the pvmove command tries to achieve an optimal rebalance, but it does not guarantee an optimal rebalance; and there are scenarios where the user can perform a more optimal rebalance manually than the one provided by the pvmove auto rebalance operation.
The auto re-balance operation does not move/re-balance boot, root, swap, or dump physical volumes, so resulting system is still bootable.
The auto re-balance will fail if the operation involves moving pre-allocated extents belonging to a snapshot. For information about pre-allocated extents of snapshots, see
Snapshot Logical Volumes” (page 103) .
Creating a Spare Disk
NOTE: Disk sparing requires the optional product HP MirrorDisk/UX.
Version 2.x volume groups do not support disk sparing.
To configure a spare physical volume into a volume group for which you want protection against disk failure, follow these steps before a disk failure actually occurs:
76 Administering LVM
1.
Use the pvcreate command to initialize the disk as an LVM disk.
NOTE: Do not use the -B option because spare physical volumes cannot contain boot information.
# pvcreate /dev/rdisk/disk3
2.
Ensure the volume group has been activated, as follows:
# vgchange -a y /dev/vg01
3.
Use the vgextend command with -z y to designate one or more physical volumes as spare physical volumes within the volume group. For example:
# vgextend -z y /dev/vg01 /dev/disk/disk3
Alternately, you can change a physical volume with no extents currently allocated within it into a spare physical volume using the pvchange command with the -z y option. For example:
# pvchange -z y /dev/disk/disk3
For more information on disk sparing, see
“Increasing Disk Redundancy Through Disk Sparing”
.
Reinstating a Spare Disk
NOTE: Disk sparing requires the optional product HP MirrorDisk/UX.
Version 2.x volume groups do not support disk sparing.
After a failed disk has been repaired or a decision has been made to replace it, follow these steps to reinstate it and return the spare disk to its former standby status:
1.
Physically connect the new or repaired disk.
2.
Restore the LVM configuration to the reconnected disk using vgcfgrestore as follows:
# vgcfgrestore -n /dev/vg01 /dev/rdisk/disk1
3.
Ensure the volume group has been activated as follows:
# vgchange -a y /dev/vg01
4.
Be sure that allocation of extents is now allowed on the replaced disk as follows:
# pvchange -x y /dev/disk/disk1
5.
Use the pvmove command to move the data from the spare to the replaced physical volume.
For example:
# pvmove /dev/disk/disk3 /dev/disk/disk1
The data from the spare disk is now back on the original disk or its replacement, and the spare disk is returned to its role as a standby empty disk.
For more information on disk sparing, see
“Increasing Disk Redundancy Through Disk Sparing”
.
Modifying Physical Volume Characteristics
The vgmodify command enables you to modify a volume group to adapt to changes in physical volumes. In particular, you can adjust the volume group to recognize size changes in physical volumes, and (for Version 1.0 volume groups only) you can change a physical volume type between bootable and nonbootable.
Beginning with the March 2009 Update, the vgmodify command can be run online (volume group activated and applications running) for Version 1.0 and Version 2.x volume groups. This allows physical volume sizes to be adjusted online. This is known as Dynamic LUN Expansion
(DLE) and Dynamic LUN Contraction (DLC).
Moving and Reconfiguring Your Disks 77
Handling Size Increases
From the LUN Side:
Disk arrays typically allow a LUN to be resized. If the volume group is activated during size increase, this is known as Dynamic LUN Expansion (DLE). If you increase the size of a LUN, follow these steps to incorporate the additional space into the volume group:
1.
Increase the LUN size using the instructions for the array.
2.
Verify that the LUN is expanded by running the diskinfo command.
From the LVM Side (for Version 1.0 Volume Groups):
Do the following for Version 1.0 volume groups.
1.
Run vgmodify to detect any physical volume size changes. It also reports whether all of the space can be made available to the volume group.
2.
If vgmodify reports that the maximum number of physical extents per physical volume
(max_pe) is too small to accommodate the new size, use vgmodify with the -t and -n options to determine a new value for max_pe, as described in
3.
Review the values by running vgmodify with the new settings and the -r option.
4.
Deactivate the volume group, if needed.
TIP: Beginning with the September 2008 Update, you can use vgmodify to recognize and accommodate size increases without deactivating the volume group. For more information, see vgmodify(1M).
5.
Commit any new value of max_pe and update the physical volume information by running vgmodify without the -r option.
6.
If needed, activate the volume group. To verify that the increased space is available, run the vgdisplay and pvdisplay commands.
From the LVM Side (for Version 2.x Volume Groups):
Do the following for Version 2.x volume groups.
NOTE: Beginning with the September 2009 Update, the vgmodify also supports Version 2.x
volume groups, but the volume groups must be in active mode to run vgmodify. For more information, see vgmodify(1M).
If the LUN for a physical volume was dynamically expanded using an array utility, the vgmodify
-E option can be used to make available the new space for user data. After the physical volume is reconfigured, you can expand logical volumes with lvextend, or you can create new logical volumes with lvcreate.
The extra space added to a physical volume through an array utility can also be used for additional
LVM configuration data when increasing the maximum VG size through the vgmodify -S option
(see
“Modifying Volume Group Parameters” (page 58)
). The vgmodify –E and –S options can also be used together to perform DLE and to increase maximum VG size increase in a single step.
To handle dynamic LUN expansion for a PV in a Version 2.x volume group, follow these steps:
1.
Use vgdisplay -v to determine which PV in the volume group require expansion and decide how much each LUN needs to be expanded. This decision can be based on which logical volumes need to grow and which PVs they can reside on. This decision can also be based on whether or not the DLE is being performed as part of increasing the maximum VG size. See the
“Modifying Volume Group Parameters” (page 58)
section for a description for
DLE in combination with increasing VG size limit.
2.
Use the vgmodify -r (review) option to verify which physical volumes require reconfiguration for DLE and to check if the reconfiguration will yield the desired result. If no PVs are specified
78 Administering LVM
on the command line, vgmodify checks all PVs in the volume group. Optionally, you can specify the PVs you want to check in the command line after the VG name. .
3.
Perform the actual DLE reconfiguration (run vgmodify without the -r review option). If no
PVs are specified, vgmodify attempts reconfiguration on all PVs in the volume group (if it detects them as having been expanded). Optionally, you can list the specific PVs you want to reconfigure in the command line after the VG name.
4.
Run vgdisplay-v to verify the result of the DLE reconfiguration: to check the total number of extents for the VG, the total number of free extents for the VG, the number of extents for each PV, and the number of free extents for each PV.
Example: Version 1.0 Volume Group
For example, to increase the size of the physical volume /dev/rdisk/disk6 from 4 GB to
100000000 KB, follow these steps:
1.
Increase the LUN size using the instructions for the disk array.
2.
Run vgmodify with the -v and -r options to check whether any disks have changed in size and whether all of the space on the physical volumes can be used.
# vgmodify -v -r vg32
Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1016
PE Size (Mbytes) 32
VGRA Size (Kbytes) 176
/dev/rdisk/disk6 Warning: Max_PE_per_PV for the volume group
(1016) too small for this PV (3051).
Using only 1016 PEs from this physical volume.
"/dev/rdisk/disk6" size changed from 4194304 to 100000000kb
An update to the Volume Group IS required
New Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1016
PE Size (Mbytes) 32
VGRA Size (Kbytes) 176
Review complete. Volume group not modified
The expanded physical volume requires 3051 physical extents to use all its space, but the current max_pe value limits this to 1016.
3.
To determine the optimal values for max_pv and max_pe, run vgmodify -t, with and without the -n as follows:
# vgmodify -t vg32
Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1016
PE Size (Mbytes) 32
VGRA Size (Kbytes) 176
VGRA space (Kbytes) without PE renumbering 896
VGRA space (Kbytes) PE renumbering lower 32768
Volume Group optimized settings (no PEs renumbered):
max_pv(-p) max_pe(-e) Disk size (Mb)
2 53756 1720193
3 35836 1146753
4 26876 860033
...
Moving and Reconfiguring Your Disks 79
28 3836 122753
30 3580 114561
32 3324 106369
35 3068 98177
38 2812 89985
...
255 252 8065
The table shows that without renumbering physical extents, a max_pv of 35 or lower permits a max_pe sufficient to accommodate the increased physical volume size.
# vgmodify -v -t -n vg32
Volume Group configuration for /dev/vg32 has been saved in
/etc/lvmconf/vg32.conf
Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1016
PE Size (Mbytes) 32
VGRA Size (Kbytes) 176
VGRA space (Kbytes) on all Physical Volumes:
PV current -n
/dev/rdisk/disk6 896 32768
/dev/rdisk/disk5 896 32768
Summary 896 32768
Volume Group optimized settings (PEs renumbered lower):
max_pv(-p) max_pe(-e) Disk size (Mb)
61 65535 2097152
62 65532 2097056
63 64252 2056096
...
251 16124 516000
252 16048 513568
255 15868 507808
The table shows that if physical extents are renumbered, all values of max_pv permit a max_pe large enough to accommodate the increased physical volume size.
For this example, select a max_pv of 10, which permits a max_pe value of 10748.
4.
Preview the changes by using the -r option to vgmodify as follows:
# vgmodify -p 10 -e 10748 -r vg32
Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1016
PE Size (Mbytes) 32
VGRA Size (Kbytes) 176
The current and new Volume Group parameters differ.
"/dev/rdisk/disk6" size changed from 4194304 to 100000000kb
An update to the Volume Group IS required
New Volume Group settings:
Max LV 255
Max PV 10
Max PE per PV 10748
PE Size (Mbytes) 32
VGRA Size (Kbytes) 896
Review complete. Volume group not modified
5.
Deactivate the volume group as follows:
# vgchange -a n vg32
Volume group "vg32" has been successfully changed.
80 Administering LVM
6.
Commit the new values as follows:
# vgmodify -p 10 -e 10748 vg32
Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1016
PE Size (Mbytes) 32
VGRA Size (Kbytes) 176
The current and new Volume Group parameters differ.
"/dev/rdisk/disk6" size changed from 4194304 to 100000000kb
An update to the Volume Group is required
New Volume Group settings:
Max LV 255
Max PV 10
Max PE per PV 10748
PE Size (Mbytes) 32
VGRA Size (Kbytes) 896
New Volume Group configuration for "vg32" has been saved in
"/etc/lvmconf/vg32.conf"
Old Volume Group configuration for "vg32" has been saved in
"/etc/lvmconf/vg32.conf.old"
Starting the modification by writing to all Physical Volumes
Applying the configuration to all Physical Volumes from
"/etc/lvmconf/vg32.conf"
Completed the modification process.
New Volume Group configuration for "vg32" has been saved in
"/etc/lvmconf/vg32.conf.old"
Volume group "vg32" has been successfully changed.
7.
Activate the volume group and verify the changes by entering the following commands:
# vgchange -a y vg32
Activated volume group
Volume group "vg32" has been successfully changed.
# vgdisplay vg32
--- Volume groups ---
VG Name /dev/vg32
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 0
Open LV 0
Max PV 10
Cur PV 2
Act PV 2
Max PE per PV 10748
VGDA 4
PE Size (Mbytes) 32
Total PE 3119
Alloc PE 0
Free PE 3119
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 1.0
Example: Version 2.x Volume Group
In this example, the vgmodify -E option is used to increase the number of extents available for user data for two LUNs whose size has been expanded by an array utility from 100 GB to 200
GB.
Moving and Reconfiguring Your Disks 81
1.
Run online vgmodify in review mode to verify that the physical volumes require reconfiguration for the DLE and to preview the number of new extents to be added:
# vgmodify -r -a -E vg1
Physical volume "/dev/disk/disk46" requires reconfiguration for expansion.
Current number of extents: 12790
Number of extents after reconfiguration: 25590
Physical volume "/dev/disk/disk46" was not changed.
Physical volume "/dev/disk/disk47" requires reconfiguration for expansion.
Current number of extents: 12790
Number of extents after reconfiguration: 25590
Physical volume "/dev/disk/disk47" was not changed.
2.
Run online vgmodify in change mode to perform the reconfiguration and add new extents to the physical volumes:
# vgmodify -a -E vg1
Reconfiguration to expand physical volume "/dev/disk/disk46" succeeded.
Previous number of extents: 12790
Number of extents after reconfiguration: 25590
Physical volume "/dev/disk/disk46" was changed.
Volume Group configuration for /dev/vg1 has been saved in
/etc/lvmconf/vg1.conf
Reconfiguration to expand physical volume "/dev/disk/disk47" succeeded.
Previous number of extents: 12790
Number of extents after reconfiguration: 25590
Physical volume "/dev/disk/disk47" was changed.
Volume Group configuration for /dev/vg1 has been saved in
/etc/lvmconf/vg1.conf
82 Administering LVM
3.
Verify that the physical volumes were reconfigured and that there are new extents available with the vgdisplay –v command:
# vgdisplay -v vg1
--- Volume groups ---
VG Name /dev/vg1
...
PE Size (Mbytes) 8
Total PE 51180
Alloc PE 25580
Free PE 25600
…
VG Version 2.1
VG Max Size 32t
VG Max Extents 4194304
…
--- Logical volumes ---
LV Name /dev/vg1/lvol1
LV Status available/syncd
LV Size (Mbytes) 102320
Current LE 12790
Allocated PE 25580
Used PV 2
--- Physical volumes ---
PV Name /dev/disk/disk46
PV Status available
Total PE 25590
Free PE 12800
…
PV Name /dev/disk/disk47
PV Status available
Total PE 25590
Free PE 12800
For more information and examples, see the Using the vgmodify Command to Perform LVM Volume
Group Dynamic LUN Expansion (DLE) and Contraction (DLC) white paper.
Moving and Reconfiguring Your Disks 83
Handling Size Decreases
CAUTION: A similar procedure can also be used when the size of a physical volume is decreased.
However, there are limitations:
•
Sequence:
The sequence must be reversed to avoid data corruption.
For an increase in size, the sequence is:
1.
Increase the LUN size from the array side.
2.
Then, increase the volume group size from the LVM side.
For a decrease in size, the sequence is:
1.
Decrease the volume group size from the LVM side.
2.
Then, decrease the LUN size from the array side.
•
Volume Group Status
Prior to the March 2009 Update, vgmodify for handling LUN contraction was only supported on Version 1.0 volume groups, and the volume group had to be deactivated before attempting any reduction. If you reduce the size of the LUN while the volume group was activated, LVM would mark the physical volume as unavailable.
Beginning with the March 2009 Update, vgmodify for handling LUN contraction can now be performed on Version 1.0 or Version 2.x volume groups and the volume group can be activated (this is known as Dynamic LUN Contraction, or DLC). For an active volume group, you can use the –C and –a options of vgmodify to recognize and accommodate size decreases without deactivating the volume group. For more information, see vgmodify(1M).
•
Physical Extent Quantity
If the physical volume has any allocated physical extents beyond the target size, vgmodify prints an error message and exits without changing the physical volume. In this case, you must be prepared to restore the LUN to its original size (ensuring the same disk space is allocated).
Supported LUN Changes per Release
This table shows what is supported with regards to whether the volume group needs to be deactivated for LUN size changes:
Table 8 Supported LUN Changes Per Release
LUN Size Decrease
Not supported
LUN Size Increase
Prior to September 2008
Update
Volume group must be deactivated; only
Version 1.0 volume groups supported.
Beginning with the
September 2008 Update
Volume group can be either deactivated or active (use vgmodify–E–a); only Version
1.0 volume group supported.
Beginning with the
March 2009 Update
Volume group can be either deactivated or active (use vgmodify–E–a); Version 1.0
and Version 2.x volume groups supported.
Not supported
Volume group can be either deactivated or active (use vgmodify–C–a); Version 1.0
and 2.x volume groups supported
Changing Physical Volume Boot Types
NOTE: Version 2.0 and 2.1 volume groups do not support bootable physical volumes.
When a physical volume is initialized for LVM use, it can be made bootable or nonbootable.
Bootable physical volumes require additional space in their LVM metadata for boot utilities and
84 Administering LVM
information. If a physical volume was accidentally initialized as bootable, you can convert the disk to a nonbootable disk and reclaim LVM metadata space.
CAUTION: The boot volume group requires at least one bootable physical volume. Do not convert all of the physical volumes in the boot volume group to nonbootable, or your system will not boot.
To change a disk type from bootable to nonbootable, follow these steps:
1.
Use vgcfgrestore to determine if the volume group contains any bootable disks.
2.
Run vgmodify twice, once with the -B n and once without it. Compare the available values for max_pe and max_pv.
3.
Choose new values for max_pe and max_pv. Review the values by running vgmodify with the new settings and the -r option.
4.
Deactivate the volume group.
5.
Commit the changes by running vgmodify without the -r option.
6.
Activate the volume group. Run the vgcfgrestore or pvdisplay commands to verify that the disk type has changed.
For example, to convert any bootable disks in volume group vg, follow these steps:
1.
Check if any physical volumes in vg01 are bootable as follows:
# vgcfgrestore -l -v -n vg01
Volume Group Configuration information in "/etc/lvmconf/vg01.conf"
VG Name /dev/vg01
---- Physical volumes : 1 ----
PV Type Size (kb) Start (kb) PVkey c2t1d0 Bootable 35566480 2912 0 max_pv 16 max_pe 1085 max_lv 255
2.
To determine which values of max_pe and max_pv are available, run the following command:
# vgmodify -t -B n vg01 /dev/rdsk/c2t1d0
Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1085
PE Size (Mbytes) 32
VGRA Size (Kbytes) 208
VGRA space (Kbytes) without PE renumbering 2784
VGRA space (Kbytes) PE renumbering lower 32768
Volume Group optimized settings (no PEs renumbered): max_pv(-p) max_pe(-e) Disk size (Mb)
5 65535 2097122
6 56828 1818498
...
255 1276 40834
Compare the values if the disk is made non-bootable, and if it is not. Enter the following command:
# vgmodify -t vg01
Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1085
PE Size (Mbytes) 32
VGRA Size (Kbytes) 208
VGRA space (Kbytes) without PE renumbering 768
VGRA space (Kbytes) PE renumbering lower 768
Volume Group optimized settings (no PEs renumbered): max_pv(-p) max_pe(-e) Disk size (Mb)
Moving and Reconfiguring Your Disks 85
1 65535 2097120
2 45820 1466240
...
255 252 8064
If you change the disk type, the VGRA space available increases from 768 KB to 2784KB (if physical extents are not renumbered) or 32768 KB (if physical extents are renumbered).
Changing the disk type also permits a larger range of max_pv and max_pe. For example, if max_pv is 255, the bootable disk can only accommodate a disk size of 8064 MB, but after conversion to nonbootable, it can accommodate a disk size of 40834 MB.
3.
For this example, select a max_pv value of 6, which permits a max_pe value of 56828.
Preview the changes by entering the following command:
# vgmodify -r -p 6 -e 56828 -B n vg01 /dev/rdsk/c2t1d0
Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1085
PE Size (Mbytes) 32
VGRA Size (Kbytes) 208
The current and new Volume Group parameters differ.
An update to the Volume Group IS required
New Volume Group settings:
Current Volume Group settings:
Max LV 255
Max PV 6
Max PE per PV 56828
PE Size (Mbytes) 32
VGRA Size (Kbytes) 2784
Review complete. Volume group not modified
4.
Deactivate the volume group as follows:
# vgchange -a n vg01
Volume group "vg01" has been successfully changed.
5.
Commit the new values as follows:
# vgmodify -p 6 -e 56828 -B n vg01 /dev/rdsk/c2t1d0
Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 1085
PE Size (Mbytes) 32
VGRA Size (Kbytes) 208
The current and new Volume Group parameters differ.
An update to the Volume Group IS required
New Volume Group settings:
Current Volume Group settings:
Max LV 255
Max PV 6
Max PE per PV 56828
PE Size (Mbytes) 32
VGRA Size (Kbytes) 2784
New Volume Group configuration for "vg01" has been saved in
"/etc/lvmconf/vg01.conf"
Old Volume Group configuration for "vg01" has been saved in
"/etc/lvmconf/vg01.conf.old"
Starting the modification by writing to all Physical Volumes
Applying the configuration to all Physical Volumes from
"/etc/lvmconf/vg01.conf"
Completed the modification process.
New Volume Group configuration for "vg01" has been saved in
86 Administering LVM
"/etc/lvmconf/vg01.conf.old"
Volume group "vg01" has been successfully changed.
6.
Activate the volume group and verify the changes as follows:
# vgchange -a y vg01
Activated volume group
Volume group "vg01" has been successfully changed.
# vgcfgbackup vg01
Volume Group configuration for /dev/vg01 has been saved in
/etc/lvmconf/vg01.conf
# vgcfgrestore -l -v -n vg01
Volume Group Configuration information in "/etc/lvmconf/vg01.conf"
VG Name /dev/vg01
---- Physical volumes : 1 ----
PV Type Size (kb) Start (kb) PVkey c2t1d0 Non-Boot 35566480 2912 0 max_pv 6 max_pe 56828 max_lv 255
Disabling a Path to a Physical Volume
IMPORTANT: This procedure only disables LVM's use of the link. The pvchange command does not prevent diagnostics or an application from accessing the physical volume.
By default, the mass storage stack uses all the paths available to access a physical volume, independently of the paths configured in LVM. Disabling a path in LVM does not prevent the native multipathing from using that path. Use the scsimgr command to disable I/O along a path or to disable the native multipathing.
You can temporarily disable LVM's use of one or all of the physical paths to a physical volume using the pvchange command. Disabling a path, also known as detaching the link, causes LVM to close that path to the device and stop using it. This can be useful if you want to guarantee that a link is idle, such as when you are running diagnostics on an I/O card, replacing an I/O card, or replacing the disk containing the physical volume.
Detaching a link to a physical volume is a temporary operation, not a permanent one. If you want to permanently remove a link or physical volume from the volume group, use vgreduce instead, as described in
“Removing a Disk from a Volume Group” (page 51)
.
To detach a link to a physical volume, use the -a option to pvchange. For example, to disable the link through the device /dev/disk/disk33, enter the following command:
# pvchange -a n /dev/disk/disk33
If you are using LVM's alternate links for multipathed disks, each link uses a different legacy device files. In that situation, to detach all links to a physical volume, use N as the argument to the -a option:
# pvchange -a N /dev/dsk/c5t0d0
Detaching one or more links to a physical volume does not necessarily cause LVM to stop using that physical volume entirely. If the detached link is the primary path to the device, LVM begins using any available alternate link to it. LVM stops using the physical volume only when all the links to it are detached.
If all the links to a device are detached, the associated physical volume becomes unavailable to the volume group. The links remain associated with the volume group but LVM does not send any
I/O requests to the physical volume until it is reattached. This means that the data on that physical volume becomes temporarily unavailable; consequently, you must make sure that any availability requirements for that data can be satisfied by mirroring before you make the device unavailable by detaching it.
Moving and Reconfiguring Your Disks 87
Detaching a link does not disable sparing. That is, if all links to a physical volume are detached and a suitable spare physical volume is available in the volume group, LVM uses it to reconstruct the detached disk. For more information on sparing, see
“Increasing Disk Redundancy Through
You can view the LVM status of all links to a physical volume using vgdisplay with the -v option.
Restoring a detached link to a physical volume, or reattaching it, makes that link available to the volume group. LVM can begin using that link as necessary to access the disk.
To reattach a specific path to a physical volume, use the pvchange command with the -a option.
For example, enter the following command:
# pvchange -a y /dev/dsk/c5t0d0
Because detaching a link to a physical volume is temporary, all detached links in a volume group are reattached when the volume group is activated, either at boot time or with an explicit vgchange command, such as the following:
# vgchange -a y /dev/vg02
Creating an Alternate Boot Disk
NOTE: Version 2.0 and 2.1 volume groups do not support bootable physical volumes. You cannot create an alternate boot disk in a Version 2.0 or 2.1 volume group.
With non-LVM disks, a single root disk contains all the attributes needed for boot, system files, primary swap, and dump. Using LVM, a single root disk is replaced by a pool of disks, a root volume group, which contains all of the same elements but allowing a root logical volume, a boot logical volume, a swap logical volume, and one or more dump logical volumes. Each of these logical volumes must be contiguous, that is, contained on a single disk, and they must have bad block relocation disabled. (Other noncontiguous logical volumes can be used for user data.) For more information on the swap and dump devices and their configuration, see HP-UX System
Administrator's Guide: Configuration Management.
The root logical volume contains the operating system software and the root file system (/).. The boot logical volume contains the boot file system (/stand). You can combine the root and boot logical volumes into a single logical volume or keep them separate. Whether you use a single combined root-boot logical volume, or separate root and boot logical volumes, the logical volume used to boot the system must be the first logical volume on its physical volume. It must begin at physical extent 0000 to boot the system in maintenance mode.
If you newly install your HP-UX system and choose the LVM configuration, a root volume group is automatically configured (/dev/vg00), as are separate root (/dev/vg00/lvol3) and boot
(/dev/vg00/lvol1) logical volumes. If you currently have a combined root and boot logical volume and you want to reconfigure to separate them after creating the boot logical volume, use the lvlnboot command with the -b option to define the boot logical volume to the system, taking effect the next time the system is booted.
The swap logical volume is the system’s primary swap area and is typically used for dump. The swap logical volume is often on the same physical disk as the root logical volume. However, you can configure it (and the dump logical volumes) on a different physical disk than the root logical volume.
If you create your root volume group with multiple disks, use the lvextend command to place the boot, root, and primary swap logical volumes on the boot disk.
TIP: You can use pvmove to move the data from an existing logical volume to another disk if necessary to make room for the root logical volume. For more information, see
“Moving Data to a Different Physical Volume” (page 73) .
To create a new root volume group with an alternate boot disk, follow these steps:
88 Administering LVM
1.
Create a bootable physical volume.
a.
On an HP Integrity server, partition the disk using the idisk command and a partition description file, then run insf as described in
“Mirroring the Boot Disk on HP Integrity
b.
Run pvcreate with the -B option. On an HP Integrity server, use the device file denoting the HP-UX partition:
# pvcreate -B /dev/rdisk/disk6_p2
On an HP 9000 server, use the device file for the entire disk:
# pvcreate -B /dev/rdisk/disk6
2.
Create a directory for the volume group. For example:
# mkdir /dev/vgroot
3.
Create a device file named group in the previously described directory as follows:
# mknod /dev/vgroot/group c 64 0xnn0000
4.
Create the root volume group, specifying each physical volume to be included, as follows:
# vgcreate /dev/vgroot /dev/disk/disk6
5.
Place boot utilities in the boot area as follows:
# mkboot /dev/rdisk/disk6
6.
Add an autoboot file to the disk boot area as follows:
# mkboot -a "hpux" /dev/rdisk/disk6
7.
Create the boot logical volume. To create a boot logical volume named bootlv with size
512 MB, enter the following commands:
# lvcreate -C y -r n -n bootlv /dev/vgroot
# lvextend –L 512 /dev/vgroot/bootlv /dev/disk/disk6
NOTE: The -r n option for bad block reallocation (in this and next two steps) is used for
Version 1.0 volume groups only. It is ignored by Version 2.x volume groups.
8.
Create the primary swap logical volume. For example, to create a primary swap logical volume named swaplv with size 2 GB on the same disks as the boot logical volume, enter the following commands:
# lvcreate -C y –r n -n swaplv /dev/vgroot
# lvextend –L 2048 /dev/vgroot/swaplv /dev/disk/disk6
9.
Create the root logical volume. For example, to create a root logical volume named rootlv with size 1 GB, enter the following commands:
# lvcreate -C y –r n -n rootlv /dev/vgroot
# lvextend –L 1024 /dev/vgroot/rootlv /dev/disk/disk6
10. Specify that bootlv is the boot logical volume as follows:
# lvlnboot -b /dev/vgroot/bootlv
11. Specify that rootlv is the root logical volume as follows:
# lvlnboot -r /dev/vgroot/rootlv
12. Specify that swaplv is the primary swap logical volume as follows:
# lvlnboot -s /dev/vgroot/swaplv
13. Specify that swaplv is also to be used for dump as follows:
# lvlnboot -d /dev/vgroot/swaplv
14. Verify the configuration as follows:
# lvlnboot -v /dev/vgroot
Boot Definitions for Volume Group /dev/vgroot:
Physical Volumes belonging in Root Volume Group:
Moving and Reconfiguring Your Disks 89
/dev/disk/disk6 -- Boot Disk
Boot: bootlv on: /dev/disk/disk6
Root: rootlv on: /dev/disk/disk6
Swap: swaplv on: /dev/disk/disk6
Dump: swaplv on: /dev/disk/disk6, 0
15. Once the boot and root logical volumes are created, create file systems for them. For example:
# mkfs –F hfs /dev/vgroot/rbootlv
# mkfs –F vxfs /dev/vgroot/rrootlv
NOTE: On HP Integrity servers, the boot file system can be VxFS. Enter the following command:
# mkfs –F vxfs /dev/vgroot/rbootlv
Mirroring the Boot Disk
NOTE: Mirroring requires the optional product, HP MirrorDisk/UX.
Version 2.0 and 2.1 volume groups do not support boot disks, so you cannot mirror the boot disk in a Version 2.0 or 2.1 volume group.
After you create mirror copies of the root, boot, and primary swap logical volumes, if any of the underlying physical volumes fail, the system can use the mirror copy on the other disk and continue.
When the failed disk comes back online, it is automatically recovered, provided the system has not been rebooted.
If the system reboots before the disk is back online, reactivate the volume group to update the LVM data structures that track the disks within the volume group. You can use vgchange -a y even though the volume group is already active.
For example, you can reactivate volume group vg00 by entering the following command:
# vgchange -a y /dev/vg00
As a result, LVM scans and activates all available disks in the volume group vg00, including the disk that came online after the system rebooted.
The procedure for creating a mirror of the boot disk is different for HP 9000 and HP Integrity servers. HP Integrity servers use partitioned boot disks.
NOTE: These examples include creating a mirror copy of the primary swap logical volume. The primary swap mirror does not need to be on a specific disk or at a specific location, but it must be allocated on contiguous disk space. The recommended mirror policy for primary swap is to have the mirror write cache and the mirror consistency recovery mechanisms disabled.
When primary swap is mirrored and your primary swap device also serves as a dump area, be sure that mirror write cache and mirror consistency recovery are set to off at boot time to avoid losing your dump. To reset these options, reboot your system in maintenance mode and use the lvchange command with the -M n and -c n options.
Mirroring the Boot Disk on HP 9000 Servers
To set up a mirrored root configuration, you must add a disk to the root volume group, mirror all the root logical volumes onto it, and make it bootable. For this example, the disk to be added is at path 0/1/1/0.0x1.0x0 and has device special files named /dev/rdisk/disk4 and /dev/ disk/disk4
. Follow these steps:
1.
Make sure the device files are in place. For example:
# insf -e -H 0/1/1/0.0x1.0x0
The following device files now exist for this disk:
/dev/[r]disk/disk4
90 Administering LVM
2.
Create a bootable physical volume as follows:
# pvcreate -B /dev/rdisk/disk4
3.
Add the physical volume to your existing root volume group as follows:
# vgextend /dev/vg00 /dev/disk/disk4
4.
Place boot utilities in the boot area as follows:
# mkboot /dev/rdisk/disk4
5.
Add an autoboot file to the disk boot area as follows:
# mkboot -a "hpux" /dev/rdisk/disk4
NOTE: If you expect to boot from this disk only when you lose quorum, you can use the alternate string hpux –lq to disable quorum checking. However, HP recommends configuring your root volume group to minimize quorum losses, by using at least three physical volumes and no single points of failure, as described in
“Planning for Recovery” (page 34)
.
6.
The logical volumes on the mirror boot disk must be extended in the same order that they are configured on the original boot disk. Determine the list of logical volumes in the root volume group and their order. For example:
# pvdisplay -v /dev/disk/disk0 | grep 'current.*0000 $'
00000 current /dev/vg00/lvol1 00000
00038 current /dev/vg00/lvol2 00000
00550 current /dev/vg00/lvol3 00000
00583 current /dev/vg00/lvol4 00000
00608 current /dev/vg00/lvol5 00000
00611 current /dev/vg00/lvol6 00000
00923 current /dev/vg00/lvol7 00000
01252 current /dev/vg00/lvol8 00000
7.
Mirror each logical volume in vg00 (the root volume group) onto the specified physical volume.
For example:
# lvextend –m 1 /dev/vg00/lvol1 /dev/disk/disk4
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
# lvextend –m 1 /dev/vg00/lvol2 /dev/disk/disk4
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
# lvextend –m 1 /dev/vg00/lvol3 /dev/disk/disk4
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
# lvextend –m 1 /dev/vg00/lvol4 /dev/disk/disk4
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
# lvextend –m 1 /dev/vg00/lvol5 /dev/disk/disk4
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
# lvextend –m 1 /dev/vg00/lvol6 /dev/disk/disk4
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
# lvextend –m 1 /dev/vg00/lvol7 /dev/disk/disk4
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
# lvextend –m 1 /dev/vg00/lvol8 /dev/disk/disk4
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
Moving and Reconfiguring Your Disks 91
TIP: To shorten the time required to synchronize the mirror copies, use the lvextend and lvsync command options introduced in the September 2007 release of HP-UX 11i Version
3. These options enable you to resynchronize logical volumes in parallel rather than serially.
For example:
# lvextend -s –m 1 /dev/vg00/lvol1 /dev/disk/disk4
# lvextend -s –m 1 /dev/vg00/lvol2 /dev/disk/disk4
# lvextend -s –m 1 /dev/vg00/lvol3 /dev/disk/disk4
# lvextend -s –m 1 /dev/vg00/lvol4 /dev/disk/disk4
# lvextend -s –m 1 /dev/vg00/lvol5 /dev/disk/disk4
# lvextend -s –m 1 /dev/vg00/lvol6 /dev/disk/disk4
# lvextend -s –m 1 /dev/vg00/lvol7 /dev/disk/disk4
# lvextend -s –m 1 /dev/vg00/lvol8 /dev/disk/disk4
# lvsync -T /dev/vg00/lvol*
8.
Update the root volume group information as follows:
# lvlnboot -R /dev/vg00
9.
Verify that the mirrored disk is displayed as a boot disk and that the boot, root, and swap logical volumes appear to be on both disks as follows:
# lvlnboot -v
10. Specify the mirror disk as the alternate boot path in nonvolatile memory as follows:
# setboot –a 0/1/1/0.0x1.0x0
11. Add a line to /stand/bootconf for the new boot disk using vi or another text editor as follows:
# vi /stand/bootconf
l /dev/disk/disk4
Where the literal “l” (lower case L) represents LVM.
Mirroring the Boot Disk on HP Integrity Servers
The procedure to mirror the root disk on Integrity servers is similar to the procedure for HP 9000 servers. The difference is that Integrity server boot disks are partitioned; you must set up the partitions, copy utilities to the EFI partition, and use the HP-UX partition device files for LVM commands.
shows the disk layout of a boot disk. The disk contains a Master Boot Record (MBR) and
EFI partition tables that point to each of the partitions. The idisk command creates the partitions
(see idisk(1M)).
Figure 5 Sample LVM Disk Layout on an HP Integrity Server
92 Administering LVM
For this example, the disk to be added is at hardware path 0/1/1/0.0x1.0x0, with device special files named /dev/disk/disk2 and /dev/rdisk/disk2. Follow these steps:
1.
Partition the disk using the idisk command and a partition description file.
a.
Create a partition description file. For example:
# vi /tmp/idf
In this example, the partition description file contains the following information:
3
EFI 500MB
HPUX 100%
HPSP 400MB
The values in the example represent a boot disk with three partitions: an EFI partition, an
HP-UX partition, and an HPSP. Boot disks of earlier HP Integrity servers might have an
EFI partition of only 100 MB and might not contain the HPSP partition.
b.
Partition the disk using idisk and your partition description file as follows:
# idisk -f /tmp/idf -w /dev/rdisk/disk2 c.
To verify that your partitions are correctly laid out, enter the following command:
# idisk /dev/rdisk/disk2
2.
Create the device files for all the partitions. For example:
# insf -e -H 0/1/1/0.0x1.0x0
The following device files now exist for this disk:
/dev/[r]disk/disk2 (this refers to the entire disk)
/dev/[r]disk/disk2_p1(this refers to the efi partition)
/dev/[r]disk/disk2_p2(this will be the hp-ux partition)
/dev/[r]disk/disk2_p3(this refers to the service partition)
3.
Create a bootable physical volume using the device file denoting the HP-UX partition. For example:
# pvcreate -B /dev/rdisk/disk2_p2
4.
Add the physical volume to your existing root volume group as follows:
# vgextend vg00 /dev/disk/disk2_p2
5.
Place boot utilities in the boot area. Copy EFI utilities to the EFI partition, and use the device special file for the entire disk as follows:
# mkboot -e -l /dev/rdisk/disk2
6.
Add an autoboot file to the disk boot area as follows:
# mkboot -a "boot vmunix" /dev/rdisk/disk2
NOTE: If you expect to boot from this disk only when you lose quorum, you can use the alternate string boot vmunix –lq to disable quorum checking. However, HP recommends configuring your root volume group to minimize quorum losses, by using at least three physical volumes and no single points of failure, as described in
“Planning for Recovery” (page 34) .
7.
The logical volumes on the mirror boot disk must be extended in the same order that they are configured on the original boot disk. Determine the list of logical volumes in the root volume group and their order. For example:
# pvdisplay -v /dev/disk/disk0_p2 | grep 'current.*0000 $'
00000 current /dev/vg00/lvol1 00000
00010 current /dev/vg00/lvol2 00000
00138 current /dev/vg00/lvol3 00000
00151 current /dev/vg00/lvol4 00000
00158 current /dev/vg00/lvol5 00000
00159 current /dev/vg00/lvol6 00000
Moving and Reconfiguring Your Disks 93
00271 current /dev/vg00/lvol7 00000
00408 current /dev/vg00/lvol8 00000
8.
Mirror each logical volume in vg00 (the root volume group) onto the specified physical volume.
For example:
# lvextend –m 1 /dev/vg00/lvol1 /dev/disk/disk2_p2
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
# lvextend –m 1 /dev/vg00/lvol2 /dev/disk/disk2_p2
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
# lvextend –m 1 /dev/vg00/lvol3 /dev/disk/disk2_p2
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
# lvextend –m 1 /dev/vg00/lvol4 /dev/disk/disk2_p2
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
# lvextend –m 1 /dev/vg00/lvol5 /dev/disk/disk2_p2
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
# lvextend –m 1 /dev/vg00/lvol6 /dev/disk/disk2_p2
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
# lvextend –m 1 /dev/vg00/lvol7 /dev/disk/disk2_p2
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
# lvextend –m 1 /dev/vg00/lvol8 /dev/disk/disk2_p2
The newly allocated mirrors are now being synchronized.
This operation will take some time. Please wait ....
NOTE: If lvextend fails with following message:
"m": illegal option
HP MirrorDisk/UX is not installed.
TIP: To shorten the time required to synchronize the mirror copies, use the lvextend and lvsync command options introduced in the September 2007 release of HP-UX 11i Version
3. These options enable you to resynchronize logical volumes in parallel rather than serially.
For example:
# lvextend -s –m 1 /dev/vg00/lvol1 /dev/disk/disk2_p2
# lvextend -s –m 1 /dev/vg00/lvol2 /dev/disk/disk2_p2
# lvextend -s –m 1 /dev/vg00/lvol3 /dev/disk/disk2_p2
# lvextend -s –m 1 /dev/vg00/lvol4 /dev/disk/disk2_p2
# lvextend -s –m 1 /dev/vg00/lvol5 /dev/disk/disk2_p2
# lvextend -s –m 1 /dev/vg00/lvol6 /dev/disk/disk2_p2
# lvextend -s –m 1 /dev/vg00/lvol7 /dev/disk/disk2_p2
# lvextend -s –m 1 /dev/vg00/lvol8 /dev/disk/disk2_p2
# lvsync -T /dev/vg00/lvol*
9.
Update the root volume group information as follows:
# lvlnboot -R /dev/vg00
10. Verify that the mirrored disk is displayed as a boot disk and that the boot, root, and swap logical volumes appear to be on both disks as follows:
# lvlnboot -v
11. Specify the mirror disk as the alternate boot path in nonvolatile memory as follows:
# setboot –a 0/1/1/0.0x1.0x0
94 Administering LVM
12. Add a line to /stand/bootconf for the new boot disk using vi or another text editor as follows:
# vi /stand/bootconf
l /dev/disk/disk2_p2
Where the literal “l” (lower case L) represents LVM.
Migrating a Volume Group to New Disks: vgmove
Beginning with September 2009 Update, LVM provides a new vgmove command to migrate data in a volume group from an old set of disks to a new set of disks.
The vgmove operation moves data in a volume group from old storage to new storage while adhering to these conditions:
•
During migration, the volume group is online with no downtime to customer applications.
•
The volume group device special file (DSF) is not changed. From an application perspective, the volume group remains unchanged.
•
The extent allocation policies used by the logical volumes stay honored.
•
The migration succeeds even if the number of destination physical volumes is different from the number of original physical volumes.
•
High availability and recoverability are not compromised at any time during the data migration.
To migrate a volume group, you provide a file containing the mapping of source (old) to destination
(new) disks, one line per source disk, in the following format: source_pv_1 destination_pv_1_1 destination_pv_1_2 ....
source_pv_2 destination_pv_2_1 destination_pv_2_2 ....
....
source_pv_n destination_pv_n_1 destination_pv_n_2 ....
This diskmap file can be manually created or generated with the -i option in vgmove, by simply providing a list of destination disks to which to migrate the volume group. Once the diskmap file is created, you can review and edit it as needed, then run vgmove again to perform the actual migration.
The vgmove syntax is:
/usr/sbin/vgmove [-A autobackup] [-p] -f diskmapfile vg_name
/usr/sbin/vgmove [-A autobackup] [-p] -i diskfile -f diskmapfile vg_name where:
-A
-p
autobackup
Sets automatic backup during this operation.
Provides a preview of the operation without actually migrating the data.
-f
diskmapfile
Specifies the file containing the mapping of source (old) to destination (new) disks
-i diskfile
vg_name
Provides a list of destination disks to generate a diskmapfile that will contain the mapping of source to destination disks. When this option is used, no actual data is migrated.
Specifies the name of the volume group whose data is to be migrated.
Example of Migrating a Volume Group to New Disks
In this example, the volume group to be migrated is called /dev/vg00 and currently resides in old disk /dev/disk/disk1. The new disks to migrate the data to are /dev/disk/disk10 and
/dev/disk/disk11
.
Migrating a Volume Group to New Disks: vgmove 95
1.
Instead of manually creating a diskmap file, mapping the old source to new destination disks, the -i option is used to generate a diskmap file for the migration. The user provides a list of destination disks, called newdiskfile in this example.
# cat newdiskfile
/dev/disk/disk10
/dev/disk/disk11
# vgmove -i newdiskfile -f diskmap.txt /dev/vg00
2.
The resulting diskmap.txt file contains the mapping of old source disks to new destination disks:
# cat diskmap.txt
/dev/disk/disk1 /dev/disk/disk10 /dev/disk/disk11
3.
Then another vgmove command is issued to actually perform the data migration:
# vgmove -f diskmap.txt /dev/vg00
Upon successful completion of data migration by vgmove, the original source disk will be automatically removed from the volume group using vgreduce. If a destination disk is not already part of the volume group, it will be added using vgextend.
After successful migration, the destination disks are added to the LVM configuration files; namely,
/etc/lvmtab or /etc/lvmtab_p. The source disks along with their alternate links are removed from the LVM configuration files.
The volume group must be activated before running the vgmove command. If the vgmove command is interrupted before it completes, the volume group is in the same state it was at the beginning of the vgmove command. The migration can be continued by running the vgmove command with the same options and disk mapping file.
NOTE: For volume groups that support bootable physical volumes (Version 1.0 and Version 2.2
or higher), vgmove supports moving boot PVs. If the diskmap file contains a mix of bootable and non-bootable source PVs, the bootable source PV must be specified first.
Migrating a Logical Volume to New Disks: lvmove
Beginning with the HP-UX 11i v3 March 2010 Update, LVM provides a new lvmove command to migrate a logical volume within a volume group. The intent is to balance a logical volume either within the existing set of physical volumes or within a new set of physical volumes in the volume group.
The volume group must be activated before running the lvmove command. If the lvmove command is interrupted before it completes, the volume group is left in a consistent state, and can still be activated. The migration can be continued by running the lvmove command with the same options and mapping file. See the lvmove(1M) manpage for more information about the lvmove command and its options.
96 Administering LVM
NOTE: For volume groups that support bootable PVs (Version 1.0 and Version 2.2 or higher), lvmove will not move root, boot, swap, or dump PVs.
The lvmove migration will fail for a space efficient snapshot that has pre-allocated extents. For more information about snapshots, see
“Creating and Administering Snapshot Logical Volumes”
Administering File System Logical Volumes
This section describes special actions you must take when working with file systems inside logical volumes. It addresses the following topics:
•
“Creating a File System” (page 97)
•
“Extending a File System” (page 98)
•
“Reducing the Size of a File System” (page 99)
•
“Backing Up a VxFS Snapshot File System” (page 101)
TIP: When dealing with file systems, you can use HP SMH or a sequence of HP-UX commands.
For most tasks, using HP SMH is quicker and simpler. You do not have to explicitly perform each of the following distinct tasks; rather, proceed from the HP SMH Disk and File Systems area. HP
SMH performs all the necessary steps for you.
Creating a File System
When creating either an HFS or VxFS file system in a logical volume, you can use HP SMH or a sequence of HP-UX commands. If you choose to use HP-UX commands directly, the following list describes the subtasks for creating a file system.
1.
If you create a new file system of a type other than HFS, you might need to reconfigure the new type into the kernel. Normally, VxFS has been configured into the kernel as part of the default configuration. See HP-UX System Administrator's Guide: Configuration Management for information on how to add a file system type.
2.
Estimate the size required for the logical volume. To estimate the size requirements for a logical volume containing a file system, see
“Setting Up Logical Volumes for File Systems” (page 21)
.
3.
Determine if there is sufficient disk space available in the volume group. Use the vgdisplay command to calculate this information, as described in
“Creating a Logical Volume” (page 52)
.
If there is not enough space within the volume group, you can add a disk to the volume group, as described in
“Adding a Disk to a Volume Group” (page 51) .
4.
Create the logical volume. Use lvcreate, as described in
.
Administering File System Logical Volumes 97
5.
Create the file system using the character device file. For example:
# newfs -F fstype /dev/vg02/rlvol1
If you do not use the -F fstype option, then newfs creates a file system based on the content of your /etc/fstab file. If there is no entry for the file system in /etc/fstab, then the file system type is determined from the file /etc/default/fs. For information on additional options, see newfs(1M).
When creating a VxFS file system, file names will be long automatically.
For HFS, use the -s or -l option to specify a file system with short or long file names, respectively. By default, the length of file system names are consistent with those of the root file system. Short file names are 14 characters maximum. Long file names allow up to 255 characters. HP recommends using long file names for flexibility; files created on other systems that use long file names can be moved to your system without being renamed.
6.
After you have created a file system, mount it for users to access it, and add it to /etc/fstab so that it is automatically mounted at boot time.
Extending a File System
Extending a file system inside a logical volume is a two-step task: extending the logical volume, then extending the file system. The first step is described in
“Extending a Logical Volume” (page 53)
.
The second step, extending the file system itself, depends on the following factors:
•
What type of file system is involved? If it is HFS or VxFS? HFS requires the file system to be unmounted to be extended.
Check the type of file system. For example:
# /usr/sbin/fstyp /dev/vg01/lvol2 vxfs
•
If the file system is VxFS, do you have the base VxFS product or the OnlineJFS product? If you have only the base VxFS product, you must unmount the file system before extending it.
To see if the OnlineJFS product is installed, enter the following command:
# swlist -l product | grep -i OnlineJFS
OnlineJFS B.11.31 Online features of the VxFS File System
•
Can you unmount the file system? To unmount system directories such as/var and /usr, you must be in single-user mode.
•
Is the file system the root file system (/)? If so, there are two complications:
◦
The logical volume containing the root file system is created with the contiguous allocation policy, so it might not be possible to extend it in place.
◦ The root file system cannot ever be unmounted, even if you change to single-user state.
If you are using VxFS as your root file system and have the OnlineJFS product, you can extend the original root file system without unmounting, provided contiguous disk space is available.
Otherwise, to extend the current root file system, you must create and mount another root disk which enables you to work with the unmounted original root disk, extending it if contiguous disk space is still available. If the original disk does not have contiguous disk space available, instead of expanding the original root disk, you can create a new root file system on another larger disk.
CAUTION: This procedure can fail on a VxFS file system already at 100% capacity (Error 28).
You must remove some files before you attempt this operation.
Once you have the answers to these questions, follow these steps:
98 Administering LVM
1.
If the file system must be unmounted, unmount it.
a.
Be sure no one has files open in any file system mounted to this logical volume and that it is no user's current working directory. For example:
# fuser -cu /work/project5
If the logical volume is in use, confirm that the underlying applications no longer need it.
If necessary, stop the applications.
NOTE: If the file system is exported using NFS to other systems, verify that no one is using those other systems, then unmount it on those systems.
b.
If you cannot stop the applications using the logical volume, or it is a system directory such as /var or/usr, change to single-user state as follows:
# /sbin/shutdown c.
Unmount the file system as follows:
# /sbin/umount /dev/vg01/lvol2
2.
Extend the logical volume. For example:
# /sbin/lvextend -L 332 /dev/vg01/lvol2
This increases the size of this volume to 332 MB.
3.
Extend the file system size to the logical volume size. If the file system is unmounted, use the extendfs command as follows:
# /sbin/extendfs /dev/vg01/rlvol2
If you did not have to unmount the file system, use the fsadm command instead. The new size is specified in terms of the block size of the file system. In this example, the block size of the file system /work/project5 is 1 KB. To extend the file system to 332 MB, the number of blocks is 339968 (332 times 1024). For example:
# fsadm -b 339968 /work/project5
4.
If you unmounted the file system, mount it again.
a.
If you had to change to single-user state, reboot the system.
# /sbin/reboot -r
You can skip any additional steps to mount the file system and export it, since the boot process mounts and exports any file systems.
b.
Remount the file system as follows:
# /sbin/mount /dev/vg01/rlvol2 /mount_point
NOTE: If the file system will continue to be used by NFS clients, export it on the server
(exportfs -a) and remount it on the clients (mount -a).
5.
Verify that the file system reflects the expansion by entering bdf, df, or fsadm -E.
Reducing the Size of a File System
You might want to shrink a file system that has been allocated more disk space than it needs, allowing that disk space to be freed for other uses.
Reducing the size of a file system is more complicated than extending it. Because of file system block allocation strategies, data can be scattered throughout the logical volume. Reducing the logical volume reclaims space at the end of the logical volume, requiring file system drivers to coalesce and rearrange data blocks ahead of time. Most types of file system are unable to do such coalescence, so you must back up the data in the file system, reduce the logical volume, create a new file system in the smaller logical volume, and restore the data from your backup.
The only current file system type able to do online coalescence and size reduction is OnlineJFS, and it can fail in some cases.
Administering File System Logical Volumes 99
Reducing a File System Created with OnlineJFS
Using the fsadm command shrinks the file system, provided the blocks it attempts to deallocate are not currently in use; otherwise, it fails. If sufficient free space is currently unavailable, file system defragmentation of both directories and extents might consolidate free space toward the end of the file system, allowing the contraction process to succeed when retried.
For example, suppose your VxFS file system is currently 6 GB. However, you decide you only need
2 GB with an additional 1 GB for reserve space. Thus, you want to resize the file system to 3 GB.
Use fsadm with the -b option to specify the new size of the file system in sectors, then reduce the size of the logical volume to match. Assuming the file system sector size is 1K, use the following commands:
# fsadm -b 3145728 /home
# lvreduce -L 3072 /dev/vg01/lvol5
Reducing a File System Created with HFS or VxFS
To reduce the size of a file system created with HFS or VxFS, follow these steps:
1.
Be sure no one has files open in any file system on the logical volume and that the logical volume is no user's current working directory. For example::
# fuser -cu /dev/vg01/lvol5
NOTE: If the file system is exported using NFS to other systems, verify that no one is using those other systems, then unmount the file system on those systems before unmounting it on the server.
2.
Back up the data in the logical volume.
For example, to back up /work/project5 to the system default tape device, enter the following command:
# tar cv /work/project5
3.
Remove the data in the file system the logical volume is mounted to, as follows:
# rm -r /work/project5
Because /work/project5 is a mount point, rm -r does not remove the directory itself.
4.
Unmount the file system to which the logical volume is mounted as follows:
# umount /work/project5
5.
Reduce the size of the logical volume as follows:
# lvreduce -L 500 /dev/vg01/lvol5
This command reduces the logical volume/dev/vg01/lvol5 to 500 MB.
6.
Create a new file system in the reduced logical volume, using the character device file. For example:
# newfs -f fstype /dev/vg01/rlvol5
7.
Mount the logical volume as follows:
# mount /dev/vg01/lvol5 /work/project5
8.
Recover the data from the backup. For example:
# tar xv
This recovers all the contents of a tape in the system default drive.
9.
If /work/project5 continues to be used by NFS clients, re-export it on the server (exportfs
-a
) and remount it on the clients (mount -a).
100 Administering LVM
Backing Up a VxFS Snapshot File System
NOTE: Creating and backing up a VxFS snapshot file system requires that you have the optional
HP OnlineJFS product installed on your system. For more information, see HP-UX System
Administrator's Guide: Configuration Management.
VxFS enables you to perform backups without taking the file system offline by making a snapshot of the file system, a read-only image of the file system at a moment in time. The primary file system remains online and continues to change. After you create the snapshot, you can back it up with any backup utility except the dump command.
To create and back up a VxFS snapshot file system, follow these steps:
1.
Determine how large the snapshot file system must be, and create a logical volume to contain it. Use bdf to assess the primary file system size and consider the following:
•
Block size of the file system (1,024 bytes per block by default)
•
How much the data in this file system is likely to change (HP recommends 15 to 20% of total file system size)
For example, to determine how large to make a snapshot of lvol4, mounted on the /home directory, examine its bdf output:
# bdf /home filesystem kbytes used avail %used mounted on
/dev/vg00/lvol4 40960 38121 2400 94% /home
Allowing for 20% change to this 40 MB file system, create a logical volume of eight blocks
(8 MB).
2.
Use lvcreate to create a logical volume to contain the snapshot file system. For example:
# lvcreate -L 8 -n snap /dev/vg02
This creates an 8 MB logical volume called /dev/vg02/snap, which can contain a snapshot file system of lvol4.
3.
Create a directory for the mount point of the snapshot file system. For example:
# mkdir /tmp/house
4.
Create and mount the snapshot file system. For example:
# mount -f vxfs -o snapof=/dev/vg00/lvol4 /dev/vg02/snap /tmp/house
In this example, a snapshot is taken of logical volume /dev/vg00/lvol4, contained in logical volume /dev/vg02/snap, and mounted on /tmp/house.
5.
Back up the snapshot file system with any backup utility except dump.
For example, use tar to archive the snapshot file system /tmp/house, ensuring that the files on the tape have relative path names, as follows:
# cd tmp; tar cf /dev/rtape/tape0BEST house
Alternatively, the following vxdump command backs up a snapshot file system /tmp/house, which has extent attributes:
# vxdump -0 -f /dev/rtape/tape0BEST /tmp/house
Administering Swap Logical Volumes
NOTE: Version 2.0 and 2.1 volume groups do not support swap logical volumes.
When you enable a swap area within a logical volume, HP-UX determines how large the area is, and it uses no more space than that. If your disk has enough remaining contiguous space, you can increase the size of your primary swap area by using the lvextend command (or HP SMH) to extend the logical volume, then reboot the system. This procedure allows HP-UX to use the extra space.
Administering Swap Logical Volumes 101
If you plan device swap areas in addition to primary swap, you get the best performance when the device swap areas are on different physical volumes. This configuration allows for the interleaving of I/O to the physical volumes when swapping occurs.
To create interleaved swap, create multiple logical volumes for swap, with each logical volume on a separate disk. You must use HP-UX commands to help you obtain this configuration. HP SMH does not allow you to create a logical volume on a specific disk. See
“Extending a Logical Volume to a Specific Disk” (page 54) .
You can configure your swap space as described in HP-UX System Administrator's Guide: Overview.
NOTE: You must reboot the system for the system to recognize changes to the swap configuration.
Creating a Swap Logical Volume
To create a swap logical volume, use the lvcreate command. You must set a contiguous allocation policy using the -C y option. For example:
# lvcreate -C y -n swap_lvol /dev/vgnn
For more information, see lvcreate(1M).
If you create a logical volume to use as primary swap, use the lvlnboot command with the -s option to update the swap information used by LVM at boot. For example:
# lvlnboot -s /dev/vgnn/swap_lvol
Extending a Swap Device
If you are using a logical volume for swap, you must increase the logical volume size before increasing the swap size. You can extend the logical volume using lvextend or HP SMH.
Swap logical volumes must be contiguous, so extending the logical volume succeeds only if there are physical extents available at the end of the existing logical volume. If contiguous disk space is not available, create a new contiguous logical volume for primary swap within the root volume group. You do not need to designate a specific disk. For example:
# lvcreate -C y -L 48 -n pswap /dev/vgroot
After creating a logical volume to use as primary swap, use lvlnboot to update the boot information:
# lvlnboot -s /dev/vgroot/pswap
Reducing the Size of a Swap Device
If you are using a logical volume for swap, you must reduce the swap size before reducing the size of the logical volume. You can reduce the size of the logical volume using lvreduce or HP
SMH.
Administering Dump Logical Volumes
NOTE: Version 2.0 and 2.1 volume groups do not support dump logical volumes.
This section describes LVM information about using logical volumes as dump devices. For information on configuring and managing dump devices, see HP-UX System Administrator's Guide: Overview.
Creating a Dump Logical Volume
To create a dump logical volume, use the lvcreate command. You must set a contiguous allocation policy using the -C y option, and disable bad block relocation using the -r n option. (Note: the
-r option is only required for Version 1.0 volume groups. It is not supported on Version 2.x and will be ignored.) For example:
# lvcreate -C y -r n -n dump_lvol /dev/vgnn
For more information, see lvcreate(1M).
102 Administering LVM
After creating a logical volume to be used as a dump device, use the lvlnboot command with the -d option to update the dump information used by LVM. If you created a logical volume /dev/ vg00/lvol2 for use as a dump area, update the boot information by entering the following:
# lvlnboot -d /dev/vg00/lvol2
Removing a Dump Logical Volume
To discontinue the use of a currently configured logical volume as a dump device, use the lvrmboot command with the -d option. For example:
# lvrmboot -d /dev/vg00/lvol2
You can then use the logical volume for other purposes. To remove the logical volume completely, see
“Removing a Logical Volume” (page 57)
.
Creating and Administering Snapshot Logical Volumes
Beginning with the HP-UX 11i v3 March 2010 Update, LVM provides the ability to create snapshot logical volumes. A snapshot represents a point-in-time image of a logical volume. LVM snapshots let you:
•
Use snapshots to back up data on the logical volume without splitting the logical volume. This reduces the space requirement.
•
Create snapshots faster than manually copying over multiple point-in-time copies of the logical volume.
•
Create multiple snapshots of a logical volume. This enables you to have images of the logical volume for multiple point in time without allocating space equivalent to the entire size of the logical volume per copy.
Up to 255 snapshots can be created off a single logical volume. The logical volume (referred to as the original logical volume) and all of its snapshots together form a snapshot tree and maintains a successor/predecessor relationship with each other.
When created, a snapshot shares all its data with that of the original logical volume. The snapshot gets a copy of its own data only when a write occurs (copy before write) onto itself or its successor.
This process is called data unsharing. The smallest unit for data unsharing is the volume group's unshare unit, specified by the vgcreate -U option. See vgcreate(1M) for details.
Snapshots are by default read-only, but the user can choose to create writable snapshots. See
lvcreate(1M) and lvchange(1M) for more details.
For more information about snapshot logical volumes and snapshot trees, see the lvm(7) manpage and the LVM Snapshot Logical Volumes white paper.
Types of Snapshots
Snapshots can be of two types: fully-allocated and space-efficient.
•
When a fully allocated snapshot is created, the number of extents required for the snapshot is allocated immediately, just like for a normal logical volume. However, the data contained in the original logical volume is not copied over to these extents. The copying of data occurs through the data unsharing process.
•
When a space-efficient snapshot is created, the user is expected to specify the number of extents that LVM needs to set aside to be used for unsharing in the future. These extents are referred to as pre-allocated extents.
When an unshare operation on a snapshot can not find the required extents in the pre-allocated extent pool, the snapshot will be marked as over-committed and inoperative. To avoid this, after the snapshot creation, the number of pre-allocated extents may be increased using the lvextend command with the -l or -L option. Refer to the lvcreate(1M) and lvextend(1M) manpages for details..
Creating and Administering Snapshot Logical Volumes 103
Beginning with the HP-UX 11i v3 September 2010 Update, LVM can be enabled to automatically increase the pre-allocated extents of a snapshot when the threshold is reached.
With this update, space efficient snapshots' threshold value can also be configured by the user. Administrators can use the lvcreate or lvchange command to enable automatic increase of pre-allocated extents (via the -e option) and specify the threshold value (via the
-P option). The threshold value and whether automatic pre-allocation is enabled are displayed in the lvdisplay command output. When automatic increase of pre-allocated extents is enabled, additional messages is printed to syslog when the threshold is reached. See these manpages for full details: lvcreate(1M), lvchange(1M), lvdisplay(1M), and lvm(7).
Creating a Snapshot Logical Volume
LVM snapshot logical volumes are created with the -S option of the lvcreate command. For example:
# lvcreate -S s -L 10 /dev/vg03/lvol1 where:
-S snap_type
-L space
Specifies the creation of a snapshot logical volume with the s value for
snap_type
.
Allocates space for the space-efficient snapshot logical volume, in megabytes.
Instead of the -L option, you can use the -l le_number option to allocate space in terms of number of pre-allocated extents. The -L and -l options are mutually exclusive. If neither the -L nor -l option is used, a fully allocated snapshot is created.
Refer to the lvcreate(1M) manpage for more details and full syntax for creating snapshot logical volumes. Refer to the
“Naming Conventions for LVM” (page 13)
section for naming conventions used for snapshot logical volumes.
NOTE: Once snapshots are created, their size and the number of mirror copies cannot be changed using the lvextend or lvreduce commands.
Removing Snapshot Logical Volumes
Any snapshot on the snapshot tree can be deleted using the lvremove command. A new lvremove option, -F, has been introduced which allows the user to delete a snapshot and all its predecessors using a single lvremove command.
For example, for a LV having 4 snapshots, where /dev/vg01/lvol1_S5 is the latest one, all of the snapshots can be deleted using the following command:
# lvremove -F /dev/vg01/lvol1_S5
Refer to the lvremove(1M) manpage for more details and full syntax for deleting logical volumes on the snapshot tree.
Displaying Snapshot Information
The vgdisplay, lvdisplay, and pvdisplay commands will now display additional information when snapshots are involved.
A summary of the additional fields displayed by these commands is listed here. See the respective manpages and the LVM Snapshot Logical Volumes white paper for more detailed information.
The vgdisplay command now additionally displays the following data:
•
The number of snapshot logical volumes in the volume group.
•
The unshare unit size for the volume group.
•
The number of pre-allocated physical extents in the volume group.
104 Administering LVM
•
The current and the maximum snapshot capacity for the volume group.
•
The listing of snapshot logical volumes and some snapshot related attributes for each.
The lvdisplay command now additionally displays the following data for a logical volume which has snapshots associated with it:
•
The number of snapshots associated with the logical volume
•
A listing of the names of the snapshot logical volumes associated with the logical volume.
For a snapshot logical volume, the following new details are displayed:
•
The LV Status will now also display the type of snapshot.
•
The state of the snapshot (operative, inoperative, over-committed, etc).
•
The total number and the current number of pre-allocated logical extents associated with the snapshot volume.
•
The number of logical extents that are currently allocated or unshared for the snapshot.
•
The current number of pre-allocated physical extents for the snapshots.
•
The name of the logical volume of which this logical volume is a snapshot.
•
The creation timestamp for the snapshot.
•
The state of whether automatic increase of pre-allocated extent is enabled or not.
•
The threshold value of a space efficient snapshot logical volume.
•
A listing of the distribution of the unshared logical and physical extents for the snapshot.
•
A listing of the pre-allocated extents for the snapshot.
•
A listing of the logical extents of the snapshot that have been unshared, and mapping of these logical extents to physical extents.
The pvdisplay command now additionally displays the following data:
•
The number of pre-allocated physical extents on it.
•
A listing of the distribution of unshared physical extents per logical volume that lie on this physical volume.
•
The extent mapping for the physical volume will indicate pre-allocated extents with a status of “pre-allocated”.
NOTE: The value of “Pre-allocated LE” should be the sum of “Current pre-allocated LE” and
“Unshared LE.” But, in some instances, this might not be shown as the case while an operation that changes the logical volume size or while unsharing of extents is in progress. The correct information will be displayed once the operation is complete.
For more information about the LVM snapshot feature and limitations when snapshots are involved, see the lvm(7) manpage and the LVM Snapshot Logical Volumes white paper.
Managing the lvmpud Daemon
The lvmpud daemon is used to handle online shared volume group reconfiguration (introduced in the HP-UX 11i v3 September 2009 Update) and automatic increase of pre-allocated extents for space efficient snapshots (introduced in the 11i v3 September 2010 Update). This daemon must be running to enable these two features.
A startup script (/sbin/init.d/lvm) is delivered as of the HP-UX 11i v3 September 2009
Update to start and stop this daemon. A configuration file (/etc/rc/config.d/lvmconf) is provided to configure automatic startup. To have lvmpud started automatically at each boot, include the following line in the /etc/rc.config.d/lvmconf file:
Managing the lvmpud Daemon 105
START_LVMPUD=1
To stop the daemon manually, use the following command:
#/sbin/init.d/lvm stop
To start the daemon manually again, use the following command:
#/sbin/init.d/lvm start
To start the lvmpud daemon even if START_LVMPUD is not set to 1, enter:
#lvmpud
See the lvmpud(1M) manpage for full details of this daemon.
Hardware Issues
This section describes hardware-specific issues dealing with LVM.
Integrating Cloned LUNs
Certain disk arrays can create clones of their LUNs. For example, the HP XP product enables you to split off a set of LUNs, called Business Copies (BCs), which are copies of existing LUNs.
Cloned disks have the same information in their LVM headers as the original disks, which violates
LVM's requirement that each disk have a unique identifier. To make the cloned disks usable with
LVM, use the vgchgid command to change their volume group identifier (VGID).
All of the physical volumes to be changed must belong to the same volume group. Therefore, if you are changing multiple physical volumes, specify all of them in a single invocation of vgchgid.
Otherwise, they are assigned different VGIDs.
For example, you have a volume group containing four physical volumes and need to create a BC for each physical volume. If you run vgchgid on only two BCs, vgchgid modifies the VGID on those two BCs. If you then run vgchgid again with all four BCs, vgchgid reports that they belong to different volume groups. To correct this, you can either run vgchgid on the two unmodified
BCs and then use the four BCs in two separate volume groups, or you can merge back the two modified BCs and split them off again before finally running vgchgid with all four BCs.
After running vgchgid on a set of physical volumes, use vgimport to import them into a new volume group. For example:
1.
Make BC copies and create new device files using the instructions for the array.
2.
Change the VGID on the cloned disks as follows:
# vgchgid /dev/rdisk/disk49 /dev/rdisk/disk50
3.
If you are using an HP-UX release before March 2008, create the volume group group file using the procedure in
“Creating the Volume Group Device File” (page 44) .
4.
Import the physical volumes as follows:
# vgimport /dev/vg04 /dev/rdisk/disk49 /dev/rdisk/disk50
5.
Back up the volume group configuration information as follows:
# vgcfgbackup /dev/vg04
6.
Activate the volume group as follows:
# vgchange -a y /dev/vg04
106 Administering LVM
4 Troubleshooting LVM
This chapter provides conceptual troubleshooting information as well as detailed procedures to help you plan for LVM problems, troubleshoot LVM, and recover from LVM failures. It contains the following information:
•
“Troubleshooting Overview” (page 107)
•
•
“Volume Group Activation Failures” (page 111)
•
“Root Volume Group Scanning” (page 114)
•
“LVM Boot Failures” (page 115)
•
“Problems After Reducing the Size of a Logical Volume” (page 115)
•
“Disk Troubleshooting and Recovery Procedures” (page 116)
•
“Reporting Problems” (page 139)
Troubleshooting Overview
This section describes LVM troubleshooting areas and tools available for troubleshooting LVM problems.
Information Collection
You can collect information about your LVM configuration using the vgdisplay, lvdisplay, pvdisplay
, and lvlnboot commands. As noted in
“Planning for Recovery” (page 34) ,
periodically collect the outputs from the commands listed in
.
Table 9 LVM Information to Collect and Maintain
Scope Command ioscan -f lvlnboot -v vgcfgrestore -l vgdisplay -v lvdisplay -v pvdisplay -v ioscan -m lun
All volume groups
All volume groups
All logical volumes
All physical volumes
Purpose
Prints I/O configuration
Prints information on root, boot, swap, and dump logical volumes.
Prints volume group configuration from the backup file.
Prints volume group information, including status of logical volumes and physical volumes.
Prints logical volume information, including mapping and status of logical extents.
Prints physical volume information, including status of physical extents.
Print I/O configuration listing the hardware path to the disk, LUN instance, LUN hardware path and lunpath hardware path to the disk.
In addition, use the lvmadm command for two purposes:
•
To determine which volume group versions are supported by your release of HP-UX 11i Version
3. For example, if your release supports Version 2.1 volume groups, lvmadm displays the following:
# lvmadm -t -V 2.1
--- LVM Limits ---
VG Version 2.1
Max VG Size (Tbytes) 2048
Max LV Size (Tbytes) 256
Troubleshooting Overview 107
Max PV Size (Tbytes) 16
Max VGs 2048
Max LVs 2047
Max PVs 2048
Max Mirrors 5
Max Stripes 511
Max Stripe Size (Kbytes) 262144
Max LXs per LV 33554432
Max PXs per PV 16777216
Max Extent Size (Mbytes) 256
If your release does not support Version 2.1 volume groups, it displays the following:
# lvmadm -t -V 2.1
Error: 2.1 is an invalid volume group version.
•
To display the contents of the /etc/lvmtab and /etc/lvmtab_p files in a human-readable fashion. For example, the following command displays the contents of the LVM configuration files for all Version 1.0 volume groups on your system:
# lvmadm -l -V 1.0
--- Version 1.0 volume groups ---
VG Name /dev/vg00
PV Name /dev/disk/disk34_p2
In addition, there are some tools available from your HP support representative:
• dump_lvmtab
: prints the contents of the /etc/lvmtab file in human-readable fashion.
• vgcfgdisplay
: prints the contents of an LVM volume group configuration backup file (as created by vgcfgbackup), such as the volume group information, the logical volume information, physical volume information and logical extent distribution.
Consistency Checks
Most LVM commands perform consistency checking. You can inspect your LVM configuration with the vgdisplay, lvdisplay, and pvdisplay commands, and look for inconsistencies.
In addition, the pvck command performs explicit consistency checking on a physical volume. This command detects bad checksums caused by a forward system migration after a backward system migration. Run pvck only on deactivated volume groups. For more information, see pvck(1M).
NOTE: The pvck command does not support Version 2.x volume groups.
Maintenance Mode Boot
LVM maintenance mode boot is a special way to boot your system that bypasses the normal LVM structures. Use it only for problems that prevent the system from otherwise booting. It is similar to single-user state in that many of the processes that normally start do not start, and many of the system checks are not performed. LVM maintenance mode is intended to enable you to boot your system long enough to repair damage to the system LVM data structures typically using vgcfgrestore
, which then enables you to boot your system normally.
Normally, the boot loader uses the LABEL file in the LIF volume to determine the location of the boot file system and the kernel /stand/vmunix. The LABEL file also contains the starting block and size of the root file system.
Under a maintenance mode boot, the boot loader attempts to find the boot file system at the start of the boot disk's user data area rather than using information from the LIF volume. To obtain the root file system's starting block and size, the boot loader reads the file /stand/rootconf. Since
LVM is not enabled, the root file system must be allocated contiguously.
108 Troubleshooting LVM
A maintenance mode boot differs from a standard boot as follows:
•
The system is booted in single-user mode.
•
No volume groups are activated.
•
Primary swap and dump are not available.
•
Only the root file system and boot file system are available.
•
If the root file system is mirrored, only one copy is used. Changes to the root file system are not propagated to the mirror copies, but those mirror copies are marked stale and will be synchronized when the system boots normally.
To boot in maintenance mode on a system with a root disk configured with LVM, use the -lm option to the boot loader. On an HP 9000 server, enter the following command:
ISL> hpux -lm
On an HP Integrity server, enter the following command:
HPUX> boot -lm
CAUTION: When you boot your system in maintenance mode, do not activate the root volume group and do not change to multiuser mode (for example, by specifying /sbin/init 2). Doing so can corrupt the root file system.
When you have repaired or restored the LVM configuration information, reboot the system using the following command:
# /sbin/reboot
For more information about LVM maintenance mode boots and troubleshooting problems with LVM structures, see Disk and File Management Tasks on HP-UX, published by Prentice Hall PTR, 1997.
I/O Errors
When a device driver returns an error to LVM on an I/O request, LVM classifies the error as either recoverable or nonrecoverable.
Recoverable Errors
When LVM encounters a recoverable (correctable) error, it internally retries the failed operation assuming that the error will correct itself or that you can take steps to correct it. Examples of recoverable errors are the following:
•
Device power failure
•
A disk that goes missing after the volume group is activated
•
A loose disk cable (which looks like a missing disk)
In these cases, LVM logs an error message to the console, but it does not return an error to the application accessing the logical volume.
If you have a current copy of the data on a separate, functioning mirror, then LVM directs the I/O to a mirror copy, the same as for a nonrecoverable error. Applications accessing the logical volume do not detect any error. (To preserve data synchronization between its mirrors, LVM retries recoverable write requests to a problematic disk, even if a current copy exists elsewhere. However, this process is managed by a daemon internal to LVM and has no impact on user access to the logical volume.)
However, if the device in question holds the only copy of the data, LVM retries the I/O request until it succeeds—that is, until the device responds or the system is rebooted. Any application performing I/O to the logical volume might block, waiting for the device to recover. In this case, your application or file system might appear to be stalled and might be unresponsive.
I/O Errors 109
Temporarily Unavailable Device
By default, LVM retries I/O requests with recoverable errors until they succeed or the system is rebooted. Therefore, if an application or file system stalls, your troubleshooting must include checking the console log for problems with your disk drives and taking action to restore the failing devices to service.
Permanently Unavailable Device
If retrying the I/O request never succeeds (for example, the disk was physically removed), your application or file system might block indefinitely. If your application is not responding, you might need to reboot your system.
As an alternative to rebooting, you can control how long LVM retries a recoverable error before treating it as nonrecoverable by setting a timeout on the logical volume. If the device fails to respond within that time, LVM returns an I/O error to the caller. This timeout value is subject to any underlying physical volume timeout and driver timeout, so LVM can return the I/O error seconds after the logical volume timeout expired.
The timeout value is normally zero, which is interpreted as an infinite timeout. Thus, no I/O request returns to the caller until it completes successfully.
View the timeout value for a logical volume using the lvdisplay command, as follows:
# lvdisplay /dev/vg00/lvol1 | grep Timeout
IO Timeout (Seconds) default
Set the timeout value using the -t option of the lvchange command. This sets the timeout value in seconds for a logical volume. For example, to set the timeout for /dev/vg01/lvol1 to one minute, enter the following command:
# lvchange -t 60 /dev/vg01/lvol1
CAUTION: Setting a timeout on a logical volume increases the likelihood of transient errors being treated as nonrecoverable errors, so any application that reads or writes to the logical volume can experience I/O errors. If your application is not prepared to handle such errors, keep the default infinite logical volume timeout.
TIP: Set the logical volume timeout to an integral multiple of any timeout assigned to the underlying physical volumes. Otherwise, the actual duration of the I/O request can exceed the logical volume timeout. For details on how to change the I/O timeout value on a physical volume, see
pvchange(1M).
Nonrecoverable Errors
Nonrecoverable errors are considered fatal; there is no expectation that retrying the operation will work.
If you have a current copy of the data on a separate, functioning mirror, then LVM directs reads and writes to that mirror copy. The I/O operation for the application accessing the logical volume completes successfully.
However, if you have no other copies of the data, then LVM returns an error to the subsystem accessing the logical volume. Thus, any application directly accessing a logical volume must be prepared for I/O requests to fail. File systems such as VxFS and most database applications are designed to recover from error situations; for example, if VxFS encounters an I/O error, it might disable access to a file system or a subset of the files in it.
LVM considers the following two situations nonrecoverable.
110 Troubleshooting LVM
Media Errors
If an I/O request fails because of a media error, LVM typically prints a message to the console log file (/var/adm/syslog/syslog.log) when the error occurs. In the event of a media error, you must replace the disk (see
“Disk Troubleshooting and Recovery Procedures” (page 116) ).
If your disk hardware supports automatic bad block relocation (usually known as hardware sparing), enable it, because it minimizes media errors seen by LVM.
NOTE: LVM does not perform software relocation of bad blocks. It recognizes and honors software relocation entries created by previous releases of LVM but does not create new ones. Enabling or disabling bad block relocation using lvchange has no effect.
Missing Device When the Volume Group Was Activated
If the device associated with the I/O was not present when the volume group was activated, LVM prints an error message to the user's terminal at activation time. You must either locate the disk and restore it to service, or replace it, then activate the volume group again.
Volume Group Activation Failures
Normally, volume groups are automatically activated during system startup. Unless you intentionally deactivate a volume group using vgchange, you do not need to manually activate volume groups.
In all cases, LVM requires that a quorum of disks in a volume group be available.
A
is the required number of physical volumes that must be available in a volume group to activate that volume group or for it to remain activated. To activate a volume group, more than
half its disks that were available during the last activation must be online and in service. For the volume group to remain fully operational, at least half the disks must remain present and available.
During run time, when a volume group is already active, if a disk fails or is taken offline, the quorum might become lost. This condition occurs if less than half of the physical volumes defined for the volume group now remain fully operational. For example, if two disks belong to a volume group, the loss of one does not cause a loss of quorum as is the case when activating the volume group.
To lose quorum, both disks must become unavailable. In that case, your volume group remains active, but a message prints to the console, indicating that the volume group has lost quorum. Until the quorum is restored (at least one of the LVM disks in the volume group in the previous example is again available), LVM does not allow you to complete most commands that affect the volume group configuration. Further, some of the I/O accesses to the logical volumes for that volume group might hang because the underlying disks are not accessible. Also, until quorum is restored, the
MWC will not be updated because LVM cannot guarantee the consistency (integrity) of the LVM information.
Use the vgchange -q n option to override the system's quorum check when the volume group is activated. This option has no effect on the runtime quorum check. Overriding quorum can result in a volume group with an inaccurate configuration (for example, missing recently creating logical volumes). This configuration change might not be reversible.
There are ways to override quorum requirements at volume group activation time or boot time.
Even when allowed by LVM, HP recommends that you do not make changes to the LVM configuration for active volume groups that do not have a quorum of disks present. To correct quorum issues,
HP recommends returning the unavailable disks to service.
Quorum Problems with a Nonroot Volume Group
If you attempt to activate a nonroot volume group when not enough disks are present to establish a quorum, vgchange displays error messages similar to the following:
# vgchange -a y /dev/vg01 vgchange: Warning: Couldn't attach to the volume group
physical volume "/dev/dsk/c1t0d2":
The path of the physical volume refers to a device that does not exist,
Volume Group Activation Failures 111
or is not configured into the kernel.
vgchange: Couldn't activate volume group "/dev/vg01":
Either no physical volumes are attached or no valid VGDAs were found on
the physical volumes.
If a nonroot volume group does not activate because of a failure to meet quorum, follow these steps:
1.
Check the power and data connections (including Fibre Channel zoning and security) of all the disks that are part of the volume group that you cannot activate. Return all disks (or at least enough to make a quorum) to service. Then use the vgchange command to activate the volume group again.
2.
If there is no other way to make a quorum available, use the -q option with the vgchange command to override the quorum requirement.
# vgchange -a y -q n /dev/vg01
The volume group activates without a quorum. You might get messages about not being able to access certain logical volumes because part or all of a logical volume might be located on one of the disks that is not present.
Whenever you override a quorum requirement, you run the risk of using data that is not current.
Be sure to check the data on the logical volumes in the activated volume group and the size and locations of the logical volumes to ensure that they are up to date.
Return the disabled disks to the volume group as soon as possible. When you return a disk to service that was not online when you originally activated the volume group, use the vgchange command as follows:
# vgchange -a y /dev/vg01
Quorum Problems with a Root Volume Group
Your root volume group can also report a quorum problem. If not enough disks are present in the root volume group to constitute a quorum, a message indicating that not enough physical volumes are present appears during the boot sequence. This error might occur if you have physically removed a disk from your system because you no longer intended to use it, but did not remove the physical volume from the volume group using vgreduce. Do not remove an LVM disk from a system without first removing it from its volume group. However, you can try to recover by booting the system with the quorum override option -lq.
On an HP 9000 server, enter the following command:
ISL> hpux -lq
On an HP Integrity server, enter the following command:
HPUX> boot -lq
Version 2.x Volume Group Activation Failures
Version 2.x volume groups can fail to activate because of insufficient quorum. For example, vgchange could display error messages similar to the following:
# vgchange -a y /dev/vgtest vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/disk/disk1":
I/O error vgchange: I/O error vgchange: Couldn't activate volume group "/dev/vgtest":
Quorum not present, or some physical volume(s) are missing.
If a Version 2.x volume group does not activate because of a failure to meet quorum, follow the steps described in
“Quorum Problems with a Nonroot Volume Group” (page 111)
.
A Version 2.x volume group can also fail activation if the necessary commands or kernel drivers are not present. For example, vgchange could display the following error message:
112 Troubleshooting LVM
# vgchange -a y /dev/vgtest vgchange: Error: The "lvmp" driver is not loaded.
Here is another possible error message:
# vgchange -a y /dev/vgtest vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/disk/disk1":
Illegal byte sequence vgchange: Couldn't activate volume group "/dev/vgtest":
Quorum not present, or some physical volume(s) are missing.
A third possible error message is the following:
# vgchange -a y /dev/vgtest vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/dsk/c1t0d0":
Cross-device link vgchange: Warning: couldn't query physical volume "/dev/dsk/c1t0d0":
The specified path does not correspond to physical volume attached to this volume group vgchange: Couldn't query the list of physical volumes.
vgchange: Couldn't activate volume group "/dev/vgtest":
Quorum not present, or some physical volume(s) are missing.
To troubleshoot these activation failures, run the lvmadm command as follows:
# lvmadm -t -V 2.0
If the necessary commands and drivers are present, lvmadm displays the following:
--- LVM Limits ---
VG Version 2.0
Max VG Size (Tbytes) 2048
Max LV Size (Tbytes) 256
Max PV Size (Tbytes) 16
Max VGs 512
Max LVs 511
Max PVs 511
Max Mirrors 6
Max Stripes 511
Max Stripe Size (Kbytes) 262144
Max LXs per LV 33554432
Max PXs per PV 16777216
Max Extent Size (Mbytes) 256
If lvmadm displays no output, your operating system release does not support Version 2.x volumes.
You must update your system to the March 2008 release of HP-UX 11i Version 3 or a newer release.
If the kernel driver to support Version 2.x volume groups is not loaded, lvmadm displays the following error:
# lvmadm -t -V 2.0 lvmadm: Error: The "lvmp" driver is not loaded.
Load the lvmp module using the kcmodule command as follows:
# kcmodule lvmp=best
==> Update the automatic 'backup' configuration first? n
* Future operations will ask whether to update the backup.
* The requested changes have been applied to the currently
running configuration.
Module State Cause Notes lvmp (before) unused loadable, unloadable
(now) loaded best
(next boot) loaded explicit
You do not need to reboot. After you load the lvmp module, lvmadm succeeds:
# lvmadm -t -V 2.0
--- LVM Limits ---
VG Version 2.0
Volume Group Activation Failures 113
Max VG Size (Tbytes) 2048
Max LV Size (Tbytes) 256
Max PV Size (Tbytes) 16
Max VGs 512
Max LVs 511
Max PVs 511
Max Mirrors 6
Max Stripes 511
Max Stripe Size (Kbytes) 262144
Max LXs per LV 33554432
Max PXs per PV 16777216
Max Extent Size (Mbytes) 256
TIP: If your system has no Version 2.x volume groups, you can free up system resources associated with lvmp by unloading it from the kernel. Run the kcmodule command as follows:
# kcmodule lvmp=unused
==> Update the automatic 'backup' configuration first? n
* Future operations will ask whether to update the backup.
* The requested changes have been applied to the currently
running configuration.
Module State Cause Notes lvmp (before) loaded explicit loadable, unloadable
(now) unused
If you later want to create Version 2.x volume groups, load the lvmp driver as described previously.
Root Volume Group Scanning
If the LVM subsystem detects that vital information is corrupted on the boot disk, it scans all the attached devices to try to find the physical volumes that are part of the root volume group. You then see the following messages on the system console and in /var/adm/syslog/syslog.log:
LVM : Failure in attaching PV (dev=0x10000nn) to the root volume group.
The physical volume does not belong to the root volume group
LVM : Failure in attaching PV (dev=0x10000nn) to the root volume group.
The physical volume does not belong to the root volume group
LVM : Activation of root volume group failed
Quorum not present, or some physical volume(s) are missing
LVM: Scanning for Root VG PVs (VGID 0xnnnnnnnn 0xnnnnnnnn)
If this root volume group scanning succeeds, messages similar to the following appear:
LVM: Rootvgscan detected 10 PV(s). Will attempt root VG activation using the following PV(s):
0x100005f 0x1000060 0x1000061 0x1000062 0x1000063 0x1000064
0x1000065 0x1000067 0x1000068 0x100006e
LVM: WARNING: Root VG activation required a scan. The PV information in
the on-disk BDRA may be out-of-date from the system's current IO
configuration. To update the on-disk BDRA, first update /etc/lvmtab
using vgscan(1M), then update the on-disk BDRA using lvlnboot(1M).
For example, if the root VG name is /dev/vg00:
1. vgscan -k -f /dev/vg00
2. lvlnboot -R /dev/vg00
LVM: Root VG activated
If this root volume group scan fails to find all physical volumes, the following message appears:
LVM: WARNING: Rootvgscan did not find any PV(s) matching root VGID.
Will attempt root VG activation using the boot device (0x10000nn).
Or the following message:
LVM: WARNING: BDRA lists the number of PV(s) for the root VG as nn, but rootvgscan found only nn. Proceeding with root VG activation.
114 Troubleshooting LVM
LVM Boot Failures
There are several reasons why an LVM configuration cannot boot. In addition to the problems associated with boots from non-LVM disks, the following problems can cause an LVM-based system not to boot.
Insufficient Quorum
In this scenario, not enough disks are present in the root volume group to meet the
requirements. At boot time, a message indicating that not enough physical volumes are available appears: panic: LVM: Configuration failure
To activate the root volume group and successfully boot the system, the number of available LVM disks must be more than half the number of LVM disks that were attached when the volume group was last active. Thus, if during the last activation there were two disks attached in the root volume group, the “more than half” requirement means that both must be available. For information on how to deal with quorum failures, see
“Volume Group Activation Failures” (page 111)
.
Corrupted LVM Data Structures on Disk
The LVM bootable disks contain vital boot information in the BDRA. This information can become corrupted, not current, or just no longer present. Because of the importance of maintaining up-to-date information within the BDRA, use the lvrmboot or lvlnboot commands whenever you make a change that affects the location of the root, boot, primary swap, or dump logical volumes.
To correct this problem, boot the system in maintenance mode as described in
Boot” (page 108) , then repair the damage to the system LVM data structures. Use vgcfgrestore
on the boot disk.
Corrupted LVM Configuration File
Another problem with activation of a volume group is a missing or corrupted /etc/lvmtab or
/etc/lvmtab_p file. After booting in maintenance mode, you can use the vgscan command to re-create the /etc/lvmtab and /etc/lvmtab_p files. For more information, see vgscan(1M).
Problems After Reducing the Size of a Logical Volume
When a file system is first created within a logical volume, it is made as large as the logical volume permits.
If you extend the logical volume without extending its file system, you can subsequently safely reduce the logical volume size, as long as it remains as big as its file system. (Use the bdf command to determine the size of your file system.) After you expand the file system, you can no longer safely reduce the size of the associated logical volume.
If you reduce the size of a logical volume containing a file system to a size smaller than that of a file system within it using the lvreduce command, you corrupt the file system. If you subsequently attempt to mount the corrupt file system, you might crash the system. If this occurs, follow these steps:
1.
Reboot your system in single-user mode.
2.
If you already have a good current backup of the data in the now corrupt file system, skip this step. If you do not have backup data and if that data is critical, try to recover whatever part of the data that might remain intact by attempting to back up the files on the file system.
Before you attempt any current backup, consider the following:
•
When your backup program accesses the corrupt part of the file system, your system will crash again. You must reboot your system again to continue with the next step.
•
There is no guarantee that all (or any) of your data on that file system will be intact or recoverable. This step is an attempt to save as much as possible. That is, any data
LVM Boot Failures 115
successfully backed up in this step will be recoverable, but some or all of your data might not be successfully backed up because of file corruption.
3.
Immediately unmount the corrupted file system if it is mounted.
4.
Use the logical volume for swap space or raw data storage, or use HP SMH or the newfs command to create a new file system in the logical volume. This new file system now matches the current reduced size of the logical volume.
5.
If you have created a new file system on the logical volume, do one of the following:
•
If you have a good prior backup (not the backup from step 2), restore its contents. Because the new file system in the smaller logical volume is smaller than the original file system, you might not have enough space to restore all your original files.
•
If you do not have a good prior backup, attempt to restore as many files as possible from any backup you made in step 2.
•
Use the new file system for creating and storing a new set of files (not for trying to restore the original files).
Disk Troubleshooting and Recovery Procedures
This section provides step-by-step procedures to handle disk failure planning, troubleshooting, and recovery, as follows:
1.
“Step 1: Preparing for Disk Recovery” (page 116)
2.
“Step 2: Recognizing a Failing Disk” (page 118)
3.
“Step 3: Confirming Disk Failure” (page 120)
4.
“Step 4: Determining Action for Disk Removal or Replacement” (page 123)
5.
“Step 5: Removing a Bad Disk” (page 126)
6.
“Step 6: Replacing a Bad Disk (Persistent DSFs)” (page 129)
7.
“Step 7: Replacing a Bad Disk (Legacy DSFs)” (page 138)
Step 1: Preparing for Disk Recovery
Recovering from system failure is a critical part of system administration. Consider the following guidelines before you experience a disk failure.
Defining a Recovery Strategy
As you create logical volumes, choose one of the following recovery strategies. Each choice strikes a balance between cost, data availability, and speed of data recovery.
•
Mirroring: If you mirror a logical volume on a separate disk, the mirror copy is online and available while recovering from a disk failure. With hot-swappable disks, users will have no indication that a disk was lost.
•
Restoring from backup: If you choose not to mirror, make sure you have a consistent backup plan for any important logical volumes. The tradeoff is that you will need fewer disks, but you will lose time while you restore data from backup media, and you will lose any data changed since your last backup
•
Initializing from scratch: If you do not mirror or back up a logical volume, be aware that you will lose data if the underlying hard disk fails. This can be acceptable in some cases, such as a temporary or scratch volume.
Using LVM Online Disk Replacement (LVM OLR)
LVM online disk replacement (LVM OLR) simplifies the replacement of disks under LVM. You can temporarily disable LVM use of a disk in an active volume group without deactivating the volume group or removing the logical volumes on the disk.
116 Troubleshooting LVM
The LVM OLR feature uses a new option (–a) in the pvchange command. The –a option disables or re-enables a specified path to an LVM disk, as used to halt LVM access to the disk under
6: Replacing a Bad Disk (Persistent DSFs)” (page 129)
or
“Step 7: Replacing a Bad Disk (Legacy
DSFs)” (page 138) . For more information, see the pvchange(1M) manpage.
Mirroring Critical Information, Especially the Root Volume Group
By making mirror copies of the root, boot, and primary swap logical volumes on another disk, you can use the copies to keep your system in operation if any of these logical volumes fail.
For details on mirroring the boot disk (which contains the root, boot, and primary swap logical volumes), see
“Mirroring the Boot Disk” (page 90)
.
There are three corollaries to the mirroring recommendation:
1.
Use the strict allocation policy for all mirrored logical volumes. Strict allocation forces mirrors to occupy different disks. Without strict allocation, you can have multiple mirror copies on the same disk; if that disk fails, you will lose all your copies. To control the allocation policy, use the –s option with the lvcreate and lvchange commands. By default, strict allocation is enabled.
2.
To improve the availability of your system, keep mirror copies of logical volumes on separate
I/O busses if possible. With multiple mirror copies on the same bus, the bus controller becomes a single point of failure—if the controller fails. If you create physical volume groups and set the allocation policy to PVG-strict, LVM helps you avoid inadvertently creating multiple mirror copies on a single bus. For more information about physical volume groups, see lvmpvg(4).
3.
Consider using one or more free disks within each volume group as spares. If you configure a disk as a spare, then a disk failure causes LVM to reconfigure the volume group so that the spare disk takes place of the failed one. That is, all the logical volumes that were mirrored on the failed disk are automatically mirrored and resynchronized on the spare, while the logical volume remains available to users. You can then schedule the replacement of the failed disk at a time of minimal inconvenience to you and your users. Sparing is particularly useful for maintaining data redundancy when your disks are not hot-swappable, since the replacement process may have to wait until your next scheduled maintenance interval. For information about disk sparing, see
“Increasing Disk Redundancy Through Disk Sparing” (page 27)
NOTE: Version 2.x volume groups do not support disk sparing.
Disk Troubleshooting and Recovery Procedures 117
Step 2: Recognizing a Failing Disk
This section explains how to look for signs that one of your disks is having problems, and how to determine which disk it is.
I/O Errors in the System Log
Often an error message in the system log file, /var/adm/syslog/syslog.log, is your first indication of a disk problem. You might see the following error
Asynchronous write failed on LUN (dev=0x3000015)
IO details : blkno : 2345, sector no : 23
See the system log errors fully described in ,
“Matching Error Messages to Physical Disks and
Volume Groups” (page 163) , where it shows how you map this type of error message to a specific
disk.
Disk Failure Notification Messages from Diagnostics
If you have Event Monitoring Service (EMS) hardware monitors installed on your system, and you enabled the disk monitor disk_em, a failing disk can trigger an event to the (EMS). Depending on how you configured EMS, you might get an email message, a message in /var/adm/syslog/ syslog.log
, or messages in another log file. EMS error messages identify a hardware problem, what caused it, and what must be done to correct it. The following example is part of an error message:
Event Time..........: Tue Oct 26 14:06:00 2004
Severity............: CRITICAL
Monitor.............: disk_em
Event #.............: 18
System..............: myhost
Summary:
Disk at hardware path 0/2/1/0.2.0 : Drive is not responding.
Description of Error:
The hardware did not respond to the request by the driver.
The I/O request was not completed.
Probable Cause / Recommended Action:
The I/O request that the monitor made to this device failed because the device timed-out. Check cables, power supply, ensure the drive is powered ON, and if needed contact your HP support representative to check the drive.
For more information on EMS, see the Diagnostics section on the http://docs.hp.com website
LVM Command Errors
Sometimes LVM commands, such as vgdisplay, return an error suggesting that a disk has problems. For example:
#vgdisplay –v | more
…
--- Physical volumes ---
PV Name /dev/dsk/c0t3d0
PV Status unavailable
Total PE 1023
Free PE 173
…
The physical volume status of unavailable indicates that LVM is having problems with the disk. You can get the same status information from pvdisplay.
The next two examples are warnings from vgdisplay and vgchange indicating that LVM has no contact with a disk:
#vgdisplay -v vg vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c0t3d0":
The specified path does not correspond to physical volume attached to
118 Troubleshooting LVM
this volume group
vgdisplay: Warning: couldn't query all of the physical volumes.
#vgchange -a y /dev/vg01 vgchange: Warning: Couldn't attach to the volume group physical volume
"/dev/dsk/c0t3d0":
A component of the path of the physical volume does not exist.
Volume group "/dev/vg01" has been successfully changed.
Another sign of disk problem is seeing stale extents in the lvdisplay command output. If there are stale extents on a logical volume even after running the vgsync or lvsync commands, you might have an issue with an I/O path or one of the disks used by the logical volume, but not necessarily the disk showing stale extents. For example:
# lvdisplay –v /dev/vg01/lvol3 | more
…
LV Status available/stale
…
--- Logical extents ---
LE PV1 PE1 Status 1 PV2 PE2 Status 2
0000 /dev/dsk/c0t3d0 0000 current /dev/dsk/c1t3d0 0100 current
0001 /dev/dsk/c0t3d0 0001 current /dev/dsk/c1t3d0 0101 current
0002 /dev/dsk/c0t3d0 0002 current /dev/dsk/c1t3d0 0102 stale
0003 /dev/dsk/c0t3d0 0003 current /dev/dsk/c1t3d0 0103 stale
…
All LVM error messages indicates which device file is associated with the problematic disk. This is useful for the next step, confirming disk failure.
See
“Messages For All LVM Commands” (page 164)
for more information on messages from LVM commands, their causes and recommended actions.
Disk Troubleshooting and Recovery Procedures 119
Step 3: Confirming Disk Failure
Once you suspect a disk has failed or is failing, make certain that the suspect disk is indeed failing.
Replacing or removing the incorrect disk makes the recovery process take longer. It can even cause data loss. For example, in a mirrored configuration, if you were to replace the wrong disk—the one holding the current good copy rather than the failing disk—the mirrored data on the good disk is lost.
It is also possible that the suspect disk is not failing. What seems to be a disk failure might be a hardware path failure; that is, the I/O card or cable might have failed. If a disk has multiple hardware paths, also known as pvlinks, one path can fail while an alternate path continues to work. For such disks, try the following steps on all paths to the disk.
If you have isolated a suspect disk, you can use hardware diagnostic tools, like Support Tools
Manager, to get detailed information about it. Use these tools as your first approach to confirm disk failure. They are documented on http://docs.hp.com in the Diagnostics area. If you do not have diagnostic tools available, follow these steps to confirm that a disk has failed or is failing:
1.
Use the ioscan command to check the S/W state of the disk. Only disks in state CLAIMED are currently accessible by the system. Disks in other states such as NO_HW or disks that are completely missing from the ioscan output are suspicious. If the disk is marked as CLAIMED, its controller is responding. For example:
# ioscan –fCdisk
Class I H/W Path Driver S/W State H/W Type Description
=================================================================== disk 0 8/4.5.0 sdisk CLAIMED DEVICE SEAGATE ST34572WC disk 1 8/4.8.0 sdisk UNCLAIMED UNKNOWN SEAGATE ST34572WC disk 2 8/16/5.2.0 sdisk CLAIMED DEVICE TOSHIBA CD-ROM XM-5401TA
In this example, the disk at hardware path 8/4.8.0 is not accessible.
If the disk has multiple hardware paths, be sure to check all the paths.
2.
You can use the pvdisplay command to check whether the disk is attached or not. A physical volume is considered to be attached, if the pvdisplay command is able to report a valid status (unavailable/available) for it. Otherwise, the disk is unattached. In that case, the disk was defective or inaccessible at the time the volume group was activated. For example, if
/dev/dsk/c0t5d0 is a path to a physical volume that is attached to LVM, enter:
# pvdisplay /dev/dsk/c0t5d0 | grep “PV Status”
PV Status available
If /dev/dsk/c1t2d3 is a path to a physical volume that is detached from LVM access using a pvchange –a n or pvchange –a N command, enter:
# pvdisplay /dev/dsk/c1t2d3 | grep “PV Status”
PV Status unavailable
If the disk responds to the ioscan command, test it with the diskinfo command. The reported size must be nonzero; otherwise, the device is not ready. For example:
# diskinfo /dev/rdsk/c0t5d0
SCSI describe of /dev/rdsk/c0t5d0:
vendor: SEAGATE
product id: ST34572WC
type: direct access
size: 0 Kbytes
bytes per sector: 512
In this example the size is 0, so the disk is malfunctioning.
3.
If both ioscan and diskinfo succeed, the disk might still be failing. As a final test, try to read from the disk using the dd command. Depending on the size of the disk, a comprehensive read can be time-consuming, so you might want to read only a portion of the disk. If the disk is functioning properly, no I/O errors are reported. The following example shows a successful read of the first 64 megabytes of the disk: When you enter the following command, look for the solid blinking green LED on the disk:
120 Troubleshooting LVM
# dd if=/dev/rdsk/c0t5d0 of=/dev/null bs=1024k count=64
64+0 records in
64+0 records out
NOTE: If the dd command hangs or takes a long time, Ctrl+C stops the read on the disk.
To run dd on the background, add & at the end of the command.
The following command shows an unsuccessful read of the whole disk:
# dd if=/dev/rdsk/c1t3d0 of=/dev/null bs=1024k dd read error: I/O error
0+0 records in 0+0 records out
4.
If the physical volume is attached but cannot be refreshed via an lvsync, it is likely there is a media problem at a specific location. Reading only the extents associated with the LE can help isolate the problem. Remember the stale extent might not have the problem. The lvsync command starts refreshing extents at LE zero and stops if it encounters an error. Therefore, find the first LE in any logical volume that is stale and test this one. For example: a.
Find the first stale LE:
# lvdisplay –v /dev/vg01/lvol3 | more
LV Status available/stale
.
.
.
--- Logical extents ---
LE PV1 PE1 Status 1 PV2 PE2 Status 2
0000 /dev/dsk/c0t3d0 0000 current /dev/dsk/c1t3d0 0100 current
0001 /dev/dsk/c0t3d0 0001 current /dev/dsk/c1t3d0 0101 current
0002 /dev/dsk/c0t3d0 0002 current /dev/dsk/c1t3d0 0102 stale
0003 /dev/dsk/c0t3d0 0003 current /dev/dsk/c1t3d0 0103 stale
In this case, LE number 2 is stale.
b.
Get the extent size for the VG:
# vgdisplay /dev/vg01 | grep –I “PE Size”
PE size (Mbytes) 32 c.
Find the start of PE zero on each disk:
For a version 1.0 VG, enter:
xd -j 0x2048 -t uI -N 4 /dev/dsk/c0t3d0
For a version 2.x VG, enter:
xd -j 0x21a4 -t uI -N 4 /dev/dsk/c0t3d0
In this example, this is a version 1.0 VG.
# xd -j 0x2048 -t uI -N 4 /dev/dsk/c0t3d0
0000000 1024
0000004
# xd -j 0x2048 -t uI -N 4 /dev/dsk/c1t3d0
0000000 1024
0000004 d.
Calculate the location of the physical extent for each PV. Multiply the PE number by the
PE size and then by 1024 to convert to Kb:
2 * 32 * 1024 = 65536
Add the offset to PE zero:
65536 + 1024 = 66560
e.
Enter the following dd commands:
# dd bs=1k skip=66560 count=32768 if=/dev/rdsk/c0t3d0 of=/dev/null
# dd bs=1k skip=66560 count=32768 if=/dev/rdsk/c1t3d0 of=/dev/null
Disk Troubleshooting and Recovery Procedures 121
Note the value calculated is used in the skip argument. The count is obtained by multiplying the PE size by 1024.
122 Troubleshooting LVM
Step 4: Determining Action for Disk Removal or Replacement
Once you know which disk is failing, you can decide how to deal with it. You can choose to remove the disk if your system does not need it, or you can choose to replace it. Before deciding on your course of action, you must gather some information to help guide you through the recovery process.
•
Is the disk hot-swappable?
You can remove or add an inactive hot-swappable hard disk drive module to a system while power is still on and the SCSI bus is still active. That is, you can replace or remove a hot-swappable disk from a system without turning off the power to the entire system.
See your system hardware manuals for information about which disks in your system are hot-swappable. Specifications for other hard disks are available in their installation manuals..
If your disk is not hot-swappable, you must schedule system down time to replace the disk.
•
Is the disk the root disk or part of the root volume group?
If the root disk is failing, the replacement process includes steps to set up the boot area; in addition, you might have to boot from its mirror if the primary root disk has failed. If a failing root disk is not mirrored, you must reinstall to the replacement disk or recover it from an
Ignite-UX backup.
To determine whether the disk is in the root volume group, use the lvlnboot command with the –v option. It lists the disks in the root volume group, and any special volumes configured on them. For example:
# lvlnboot –v
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/disk/disk47_p2 -- Boot Disk
Boot: lvol1 on: /dev/disk/disk47_p2
Root: lvol3 on: /dev/disk/disk47_p2
Swap: lvol2 on: /dev/disk/disk47_p2
Dump: lvol2 on: /dev/disk/disk47_p2, 0
•
What logical volumes are on the disk, and are they mirrored?
If you plan to replace the disk, you might need to restore data from backups. However, you must only recover data for a subset of the logical volumes in the volume group. Only the logical volumes that actually have physical extents on the disk are affected. In addition, if a logical volume is mirrored, there is probably a current copy of the data on the mirror, so it does not need to be recovered from backup.
You can find the list of logical volumes using the disk with the pvdisplay command. With the –v option, pvdisplay shows a listing of all the physical extents on a physical volume and to what logical volume they belong. This list is long; pipe it to more or send it to a file.
For example:
# pvdisplay -v /dev/disk/disk3 | more
...
--- Distribution of physical volume ---
LV Name LE of LV PE for LV
/dev/vg00/lvol5 50 50
/dev/vg00/lvol6 245 245
...
In this example, logical volumes /dev/vg00/lvol5 and /dev/vg00/lvol6 have physical extents on this disk, so you must restore lvol5 and lvol6 only.
If pvdisplay fails, you have the following options. You can refer to any configuration documentation you created in advance.
Alternatively, you can run lvdisplay -v on all the logical volumes in the volume groups and see if any extents are mapped to an unavailable physical volume. The lvdisplay
Disk Troubleshooting and Recovery Procedures 123
command shows '???' for the physical volume if it is unavailable. The issue with this approach is that it does not show precisely how many disks are unavailable. To ensure that multiple simultaneous disk failures have not occurred, run vgdispay to check the difference between the number of active and number of current physical volumes. For example, a difference of one means only one disk is failing.
A third option for determining which logical volumes are on the disk is to use the vgcfgdisplay command, available from your HP support representative.
For each of the logical volumes affected, use lvdisplay to determine if the number of mirror copies is greater than zero. This verifies that the logical volume is mirrored. For example:
# lvdisplay /dev/vg00/lvol1
--- Logical volumes ---
LV Name /dev/vg00/lvol1
VG Name /dev/vg00
LV Permission read/write
LV Status available/syncd
Mirror copies 1
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 300
Current LE 75
Allocated PE 150
Stripes 0
Stripe Size (Kbytes) 0
Bad block off
Allocation strict/contiguous
IO Timeout (Seconds) default
The number of mirror copies is not zero; therefore, the logical volume is mirrored.
Use lvdisplay again to determine which logical extents are mapped onto the suspect disk, and whether there is a current copy of that data on another disk. With the –v option, lvdisplay shows every logical extent, its mapping to any physical extents, and the status of those physical extents (stale or current).
This listing can be quite long, so use grep to confine the listing to the disk that is being replaced. For example:
# lvdisplay -v /dev/vg00/lvol1 | grep –e /dev/disk/disk3 –e ’???’
00000 /dev/disk/disk3 00000 current /dev/disk/disk6 00000 current
00001 /dev/disk/disk3 00001 current /dev/disk/disk6 00001 current
00002 /dev/disk/disk3 00002 current /dev/disk/disk6 00002 current
00003 /dev/disk/disk3 00003 current /dev/disk/disk6 00003 current
00004 /dev/disk/disk3 00004 current /dev/disk/disk6 00004 current
00005 /dev/disk/disk3 00005 current /dev/disk/disk6 00005 current
...
In this example, all lvol1 physical extents on /dev/disk/disk3 have a current copy elsewhere on the system, specifically on /dev/disk/disk6. If /dev/disk/disk3 was unavailable when the volume group was activated, its column contains a ‘???’ instead of the disk name.
124 Troubleshooting LVM
NOTE: There might be an instance where you see that only the failed physical volume holds the current copy of a given extent (and all other mirror copies of the logical volume hold the stale data for that given extent), and LVM does not permit you to remove that physical volume from the volume group. In this case, use the lvunstale command (available from your HP support representative) to mark one of the mirror copies as “nonstale” for that given extent.
HP recommends you use the lvunstale tool with caution.
Based on the gathered information, choose the appropriate disk removal or disk replacement procedure, detailed on the following pages. The possible scenarios are:
•
“Step 5: Removing a Bad Disk” (page 126)
•
“Step 6: Replacing a Bad Disk (Persistent DSFs)” (page 129)
•
“Step 7: Replacing a Bad Disk (Legacy DSFs)” (page 138)
Disk Troubleshooting and Recovery Procedures 125
Step 5: Removing a Bad Disk
You can elect to remove the failing disk from the system instead of replacing it if you are certain that another valid copy of the data exists or the data can be moved to another disk.
Removing a Mirror Copy from a Disk
If you have a mirror copy of the data already, you can stop LVM from using the copy on the failing disk by reducing the number of mirrors. To remove the mirror copy from a specific disk, use lvreduce
, and specify the disk from which to remove the mirror copy.
For example (if you have a single mirror copy):
# lvreduce -m 0 -A n /dev/vgname/lvname bad_disk_path
Or, if you have two mirror copies:
# lvreduce -m 1 -A n /dev/vgname/lvname bad_disk_path
The –A n option is used to prevent the lvreduce command from performing an automatic vgcfgbackup operation, which might hang while accessing a defective disk.
If you have only a single mirror copy and want to maintain redundancy, as soon as possible, create a second mirror of the data on a different, functional disk, subject to the mirroring guidelines, described in
“Step 1: Preparing for Disk Recovery” (page 116)
, before you run lvreduce.
Removing Mirror Copy from Ghost Disk
One might encounter a situation where you have to remove from the volume group a failed physical volume or a physical volume that is not actually connected to the system but is still recorded in the
LVM configuration file. Such a physical volume is sometimes called a ghost disk or phantom disk.
You can get a ghost disk if the disk has failed before volume group activation, possibly because the system was rebooted after the failure.
A ghost disk is usually indicated by vgdisplay reporting more current physical volumes than active ones. Additionally, LVM commands might complain about the missing physical volumes as follows:
# vgdisplay vg01 vgdisplay: Warning: couldn't query physical volume "/dev/dsk/c5t5d5":
The specified path does not correspond to physical volume attached to this volume group vgdisplay: Couldn't query the list of physical volumes.
--- Volume groups ---
VG Name /dev/vg01
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 3
Open LV 3
Max PV 16
Cur PV 2 (#No. of PVs belonging to vg01)
Act PV 1 (#No. of PVs recorded in the kernel)
Max PE per PV 4350
VGDA 2
PE Size (Mbytes) 8
Total PE 4341
Alloc PE 4340
Free PE 1
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
In these situations where the disk was not available at boot time, or the disk has failed before volume group activation (pvdisplay failed), the lvreduce command fails with an error that it could not query the physical volume. You can still remove the mirror copy, but you must specify the physical volume key rather than the name.
126 Troubleshooting LVM
The physical volume key of a disk indicates its order in the volume group. The first physical volume has the key 0, the second has the key 1, and so on. This need not be the order of appearance in
/etc/lvmtab file although it is usually the case, at least when a volume group is initially created.
You can use the physical volume key to address a physical volume that is not attached to the volume group. This usually happens if it was not accessible during activation, for example, because of a hardware or configuration problem. You can obtain the key using lvdisplay with the –k option as follows:
# lvdisplay -v –k /dev/vg00/lvol1
…
--- Logical extents ---
LE PV1 PE1 Status 1 PV2 PE2 Status 2
00000 0 00000 stale 1 00000 current
00001 0 00001 stale 1 00001 current
00002 0 00002 stale 1 00002 current
00003 0 00003 stale 1 00003 current
00004 0 00004 stale 1 00004 current
00005 0 00005 stale 1 00005 current
…
Compare this output with the output of lvdisplay without –k, that was used to check the mirror status. The column that contained the failing disk (or ’???’) now holds the key. For this example, the key is 0. Use this key with lvreduce. For example, if you have a single mirror copy:
# lvreduce -m 0 -A n –k /dev/vgname/lvname key
Or, if you have two mirror copies:
# lvreduce -m 1 -A n –k /dev/vgname/lvname key
Moving the Physical Extents to Another Disk
If the disk is partially available and you can still read from it, you can move the data onto another disk by moving the physical extents onto another disk. The pvmove command moves logical volumes or certain extents of a logical volume from one physical volume to another. It is typically used to free up a disk; that is, to move all data from that physical volume so it can be removed from the volume group. In its simplest invocation, you specify the disk to free up, and LVM moves all the physical extents on that disk to any other disks in the volume group, subject to any mirroring allocation policies. For example:
# pvmove pvname
NOTE: The pvmove command will fail if the logical volume is striped.
The pvmove command provides many features to move data from a disk. See
Different Physical Volume” (page 73)
for more information and pvmove examples. The pvmove(1M) manpage describes all the command's features and options.
Removing the Disk from the Volume Group
After the disk no longer holds any logical extents, you can use the vgreduce command to remove the physical volume from the volume group so it is not inadvertently used again. Check for alternate links before removing the disk, since you must remove all the paths to a multipathed disk. Use the pvdisplay command as follows:
# pvdisplay /dev/dsk/c0t5d0
--- Physical volumes ---
PV Name /dev/dsk/c0t5d0
PV Name /dev/dsk/c1t6d0 Alternate Link
VG Name /dev/vg01
PV Status available
Allocatable yes
VGDA 2
Cur LV 0
PE Size (Mbytes) 4
Disk Troubleshooting and Recovery Procedures 127
Total PE 1023
Free PE 1023
Allocated PE 0
Stale PE 0
IO Timeout (Seconds) default
Autoswitch On
In this example, there are two entries for PV Name. Use the vgreduce command to reduce each path as follows:
# vgreduce vgname /dev/dsk/c0t5d0
# vgreduce vgname /dev/dsk/c1t6d0
If the disk is unavailable, the vgreduce command fails. You can still forcibly reduce it, but you must then rebuild the lvmtab, which has two side effects. First, any deactivated volume groups are left out of the lvmtab, so you must manually vgimport them later. Second, if any multipathed disks have their link order reset, and if you arranged your pvlinks to implement load-balancing, you might have to arrange them again.
Starting with the HP-UX 11i v3 release, there is a new feature introduced in the mass storage subsystem that also supports multiple paths to a device and allows access to the multiple paths simultaneously. If the new multi-path behavior is enabled on the system, and the imported volume groups were configured with only persistent device special files, there is no need to arrange them again.
If needed, use the following steps to rebuild the LVM configuration files (/etc/lvmtab or /etc/ lvmtab_p
):
# vgreduce –f vgname pvname
# vgscan –f vgname
In cases where the physical volume is not readable (for example, when the physical volume is unattached either because the disk failed before volume group activation or because the system has been rebooted after the disk failure), running the vgreduce command with the -f option on those physical volumes removes them from the volume group, provided no logical volumes have extents mapped on that disk. Otherwise, if the unattached physical volume is not free,- vgreduce
-f reports an extent map to identify the associated logical volumes. You must free all physical extents using lvreduce or lvremove before you can remove the physical volume with the vgreduce command.
This completes the procedure for removing the disk from your LVM configuration. If the disk hardware allows it, you can remove it physically from the system. Otherwise, physically remove it at the next scheduled system reboot.
128 Troubleshooting LVM
Step 6: Replacing a Bad Disk (Persistent DSFs)
If instead of removing the disk, you need to replace the faulty disk, this section provides a step-by-step guide to replacing a faulty LVM disk, for systems configured with persistent DSFs. For systems using legacy DSFs, refer to the next step
“Step 7: Replacing a Bad Disk (Legacy DSFs)”
If you have any questions about the recovery process, contact your local HP Customer Response
Center for assistance.
Because disks are physical devices, their hardware can fail, necessitating their replacement. After a failing disk is replaced with a new one (retaining the hardware address of the original disk to avoid confusion), the data must be restored to that disk from a backup.
Since the disk was under LVM control, it can have physical extents for several logical volumes on it. The layout of those logical volumes must first be restored and the data for each of those logical volumes restored from backup (if the data is not on a mirror copy).
There are basically four scenarios for replacing a bad disk. Determine your particular case and follow the steps provided for your scenario:
•
“Replacing a Mirrored Nonboot Disk” (page 129)
•
“Replacing an Unmirrored Nonboot Disk” (page 131)
•
“Replacing a Mirrored Boot Disk” (page 134)
•
“Replacing an Unmirrored Boot Disk” (page 137)
Replacing a Mirrored Nonboot Disk
Use this procedure if all the physical extents on the disk have copies on another disk, and the disk is not a boot disk. If the disk contains any unmirrored logical volumes or any mirrored logical volumes without an available and current mirror copy, see
“Replacing an Unmirrored Nonboot
.
For this example, the disk to be replaced is at lunpath hardware path 0/1/1/1.0x3.0x0, with device special files named /dev/disk/disk14 and /dev/rdisk/disk14. Follow these steps:
1.
Save the hardware paths to the disk.
Run the ioscan command and note the hardware paths of the failed disk.
# ioscan –m lun /dev/disk/disk14
Class I Lun H/W Path Driver S/W State H/W Type Health Description
======================================================================== disk 14 64000/0xfa00/0x0 esdisk CLAIMED DEVICE offline HP MSA Vol
0/1/1/1.0x3.0x0
/dev/disk/disk14 /dev/rdisk/disk14
In this example, the LUN instance number is 14, the LUN hardware path is
64000/0xfa00/0x0, and the lunpath hardware path is 0/1/1/1.0x3.0x0.
When the failed disk is replaced, a new LUN instance and LUN hardware path are created.
To identify the disk after it is replaced, you must use the lunpath hardware path
(0/1/1/1.0x3.0x0).
2.
Halt LVM access to the disk.
If the disk is not hot-swappable, power off the system to replace it. By shutting down the system, you halt LVM access to the disk, so you can skip this step.
If the disk is hot-swappable, detach it using the –a option of the pvchange command:
# pvchange -a N /dev/disk/disk14
3.
Replace the disk.
For the hardware details on how to replace the disk, see the hardware administrator's guide for the system or disk array.
Disk Troubleshooting and Recovery Procedures 129
If the disk is hot-swappable, replace it.
If the disk is not hot-swappable, shut down the system, turn off the power, and replace the disk. Reboot the system.
4.
Notify the mass storage subsystem that the disk has been replaced.
If the system was not rebooted to replace the failed disk, then run scsimgr before using the new disk as a replacement for the old disk. For example:
# scsimgr replace_wwid –D /dev/rdisk/disk14
This command allows the storage subsystem to replace the old disk’s LUN World-Wide-Identifier
(WWID) with the new disk’s LUN WWID. The storage subsystem creates a new LUN instance and new device special files for the replacement disk.
5.
Determine the new LUN instance number for the replacement disk.
For example:
# ioscan –m lun
Class I Lun H/W Path Driver S/W State H/W Type Health Description
======================================================================== disk 14 64000/0xfa00/0x0 esdisk NO_HW DEVICE offline HP MSA Vol
/dev/disk/disk14 /dev/rdisk/disk14
...
disk 28 64000/0xfa00/0x1c esdisk CLAIMED DEVICE online HP MSA Vol
0/1/1/1.0x3.0x0
/dev/disk/disk28 /dev/rdisk/disk28
In this example, LUN instance 28 was created for the new disk, with LUN hardware path
64000/0xfa00/0x1c, device special files /dev/disk/disk28 and /dev/rdisk/disk28, at the same lunpath hardware path as the old disk, 0/1/1/1.0x3.0x0. The old LUN instance
14 for the old disk now has no lunpath associated with it.
NOTE: If the system was rebooted to replace the failed disk, then ioscan –m lun does not display the old disk.
6.
Assign the old instance number to the replacement disk.
For example:
# io_redirect_dsf -d /dev/disk/disk14 -n /dev/disk/disk28
This assigns the old LUN instance number (14) to the replacement disk. In addition, the device special files for the new disk are renamed to be consistent with the old LUN instance number.
The following ioscan –m lun output shows the result:
# ioscan –m lun /dev/disk/disk14
Class I Lun H/W Path Driver S/W State H/W Type Health Description
======================================================================== disk 14 64000/0xfa00/0x1c esdisk CLAIMED DEVICE online HP MSA Vol
0/1/1/1.0x3.0x0
/dev/disk/disk14 /dev/rdisk/disk14
The LUN representation of the old disk with LUN hardware path 64000/0xfa00/0x0 was removed. The LUN representation of the new disk with LUN hardware path
64000/0xfa00/0x1c was reassigned from LUN instance 28 to LUN instance 14 and its device special files were renamed as /dev/disk/disk14 and /dev/rdisk/disk14.
7.
Restore LVM configuration information to the new disk.
For example:
# vgcfgrestore -n /dev/vgnn /dev/rdisk/disk14
130 Troubleshooting LVM
8.
Restore LVM access to the disk.
If you did not reboot the system in
Step 2 , “Halt LVM access to the disk,” reattach the disk as
follows:
# pvchange –a y /dev/disk/disk14
If you did reboot the system, reattach the disk by reactivating the volume group as follows:
# vgchange -a y /dev/vgnn
NOTE: The vgchange command with the -a y option can be run on a volume group that is deactivated or already activated. It attaches all paths for all disks in the volume group and resumes automatically recovering any disks in the volume group that had been offline or any disks in the volume group that were replaced. Therefore, run vgchange only after all work has been completed on all disks and paths in the volume group, and it is necessary to attach them all.
Because all the data on the replaced disk was mirrored, you do not need to do anything else; LVM automatically synchronizes the data on the disk with the other mirror copies of the data.
Replacing an Unmirrored Nonboot Disk
Use this procedure if any of the physical extents on the disk do not have mirror copies elsewhere, and your disk is not a boot disk.
In this example, the disk to be replaced is at lunpath hardware path 0/1/1/1.0x3.0x0, with device special files named /dev/disk/disk14 and /dev/rdisk/disk14. Follow these steps:
1.
Save the hardware paths to the disk.
Run the ioscan command and note the hardware paths of the failed disk.
# ioscan –m lun /dev/disk/disk14
Class I Lun H/W Path Driver S/W State H/W Type Health Description
======================================================================== disk 14 64000/0xfa00/0x0 esdisk CLAIMED DEVICE offline HP MSA Vol
0/1/1/1.0x3.0x0
/dev/disk/disk14 /dev/rdisk/disk14
In this example, the LUN instance number is 14, the LUN hardware path is
64000/0xfa00/0x0, and the lunpath hardware path is 0/1/1/1.0x3.0x0.
When the failed disk is replaced, a new LUN instance and LUN hardware path are created.
To identify the disk after it is replaced, you must use the lunpath hardware path
(0/1/1/1.0x3.0x0).
2.
Halt LVM access to the disk.
If the disk is not hot-swappable, power off the system to replace it. By shutting down the system, you halt LVM access to the disk, so you can skip this step.
If the disk is hot-swappable, disable user and LVM access to all unmirrored logical volumes.
First, disable user access to all unmirrored logical volumes. Halt any applications and unmount any file systems using these logical volumes. This prevents the applications or file systems from writing inconsistent data over the newly restored replacement disk.
For each unmirrored logical volume using the disk: a.
Use the fuser command to make sure no one is accessing the logical volume, either as a raw device or as a file system. If users have files open in the file system or it is their current working directory, fuser reports their process IDs.
For example, if the logical volume was /dev/vg01/lvol1, enter the following command:
# fuser -cu dev/vg01/lvol1
/dev/vg01/lvol1: 27815c(root) 27184c(root)
Disk Troubleshooting and Recovery Procedures 131
b.
If fuser reports process IDs using the logical volume, use the ps command to map the list of process IDs to processes, and then determine whether you can halt those processes.
For example, look up processes 27815 and 27184 as follows:
# ps -fp27815 -p27184
UID PID PPID C STIME TTY TIME COMMAND
root 27815 27184 0 09:04:05 pts/0 0:00 vi test.c
root 27184 27182 0 08:26:24 pts/0 0:00 -sh c.
If so, use fuser with the –k option to kill all processes accessing the logical volume.
The example processes are noncritical, so kill them as follows:
# fuser -ku dev/vg01/lvol1
/dev/vg01/lvol1: 27815c(root) 27184c(root) d.
If the logical volume is being used as a file system, unmount it as follows:
# umount /dev/vg01/lvol1
NOTE: If you cannot stop the applications using the logical volume, or you cannot unmount the file system, you must shut down the system.
After disabling user access to the unmirrored logical volumes, disable LVM access to the disk:
# pvchange -a N /dev/disk/disk14
3.
Replace the disk.
For the hardware details on how to replace the disk, see the hardware administrator’s guide for the system or disk array.
If the disk is hot-swappable, replace it.
If the disk is not hot-swappable, shut down the system, turn off the power, and replace the disk. Reboot the system.
4.
Notify the mass storage subsystem that the disk has been replaced.
If the system was not rebooted to replace the failed disk, then run scsimgr before using the new disk as a replacement for the old disk. For example:
# scsimgr replace_wwid –D /dev/rdisk/disk14
This command allows the storage subsystem to replace the old disk’s LUN World-Wide-Identifier
(WWID) with the new disk’s LUN WWID. The storage subsystem creates a new LUN instance and new device special files for the replacement disk.
5.
Determine the new LUN instance number for the replacement disk.
For example:
# ioscan –m lun
Class I Lun H/W Path Driver S/W State H/W Type Health Description
======================================================================== disk 14 64000/0xfa00/0x0 esdisk NO_HW DEVICE offline HP MSA Vol
/dev/disk/disk14 /dev/rdisk/disk14
...
disk 28 64000/0xfa00/0x1c esdisk CLAIMED DEVICE online HP MSA Vol
0/1/1/1.0x3.0x0
/dev/disk/disk28 /dev/rdisk/disk28
In this example, LUN instance 28 was created for the new disk, with LUN hardware path
64000/0xfa00/0x1c, device special files /dev/disk/disk28 and /dev/rdisk/disk28, at the same lunpath hardware path as the old disk, 0/1/1/1.0x3.0x0. The old LUN instance
14 for the old disk now has no lunpath associated with it.
132 Troubleshooting LVM
NOTE: If the system was rebooted to replace the failed disk, then ioscan –m lun does not display the old disk.
6.
Assign the old instance number to the replacement disk.
For example:
# io_redirect_dsf -d /dev/disk/disk14 -n /dev/disk/disk28
This assigns the old LUN instance number (14) to the replacement disk. In addition, the device special files for the new disk are renamed to be consistent with the old LUN instance number.
The following ioscan –m lun output shows the result:
# ioscan –m lun /dev/disk/disk14
Class I Lun H/W Path Driver S/W State H/W Type Health Description
======================================================================== disk 14 64000/0xfa00/0x1c esdisk CLAIMED DEVICE online HP MSA Vol
0/1/1/1.0x3.0x0
/dev/disk/disk14 /dev/rdisk/disk14
The LUN representation of the old disk with LUN hardware path 64000/0xfa00/0x0 was removed. The LUN representation of the new disk with LUN hardware path
64000/0xfa00/0x1c was reassigned from LUN instance 28 to LUN instance 14 and its device special files were renamed as /dev/disk/disk14 and /dev/rdisk/disk14.
7.
Restore LVM configuration information to the new disk.
For example:
# vgcfgrestore -n /dev/vgnn /dev/rdisk/disk14
8.
Restore LVM access to the disk.
If you did not reboot the system in
Step 2 , “Halt LVM access to the disk,” reattach the disk as
follows:
# pvchange –a y /dev/disk/disk14
If you did reboot the system, reattach the disk by reactivating the volume group as follows:
# vgchange -a y /dev/vgnn
NOTE: The vgchange command with the -a y option can be run on a volume group that is deactivated or already activated. It attaches all paths for all disks in the volume group and resumes automatically recovering any disks in the volume group that had been offline or any disks in the volume group that were replaced.
Therefore, run vgchange only after all work has been completed on all disks and paths in the volume group, and it is necessary to attach them all.
Disk Troubleshooting and Recovery Procedures 133
9.
Recover any lost data.
LVM recovers all the mirrored logical volumes on the disk, and starts that recovery when the volume group is activated.
For all the unmirrored logical volumes that you identified in
Step 2 , “Halt LVM access to the
disk,” restore the data from backup and reenable user access as follows:
•
For raw volumes, restore the full raw volume using the utility that was used to create your backup. Then restart the application.
•
For file systems, you must re-create the file systems first. For example:
# newfs -F fstype /dev/vgnn/rlvolnn
Use the logical volume's character device file for the newfs command. For file systems that had nondefault configurations, see newfs(1M) for the correct options.
After creating the file system, mount it under the mount point that it previously occupied.
Then restore the data for that file system from your full backups.
TIP: To make the file system restoration step easier, record how they were originally created. You can change other file system parameters, such as those used to tune file system performance. The file system must be at least as large as before the disk failure.
Replacing a Mirrored Boot Disk
There are two additional operations you must perform when replacing a mirrored boot disk:
1.
You must initialize boot information on the replacement disk.
2.
If the replacement requires rebooting the system, and the primary boot disk is being replaced, you must boot from the alternate boot disk.
In this example, the disk to be replaced is at lunpath hardware path 0/1/1/1.0x3.0x0, with device special files named /dev/disk/disk14 and /dev/rdisk/disk14. The system is an
HP Integrity server, so the physical volume names must specify the HP-UX partition on the boot disk
(/dev/disk/disk14_p2 and /dev/disk/disk14_p2).
1.
Save the hardware paths to the disk.
Run the ioscan command and note the hardware paths of the failed disk as follows:
# ioscan –m lun /dev/disk/disk14
Class I Lun H/W Path Driver S/W State H/W Type Health Description
======================================================================== disk 14 64000/0xfa00/0x0 esdisk CLAIMED DEVICE offline HP MSA Vol
0/1/1/1.0x3.0x0
/dev/disk/disk14 /dev/rdisk/disk14
/dev/disk/disk14_p1 /dev/rdisk/disk14_p1
/dev/disk/disk14_p2 /dev/rdisk/disk14_p2
/dev/disk/disk14_p3 /dev/rdisk/disk14_p3
In this example, the LUN instance number is 14, the LUN hardware path is
64000/0xfa00/0x0, and the lunpath hardware path is 0/1/1/1.0x3.0x0.
When the failed disk is replaced, a new LUN instance and LUN hardware path are created.
To identify the disk after it is replaced, you must use the lunpath hardware path
(0/1/1/1.0x3.0x0).
2.
Halt LVM access to the disk.
If the disk is not hot-swappable, power off the system to replace it. By shutting down the system, you halt LVM access to the disk, so you can skip this step.
If the disk is hot-swappable, detach the device using the –a option of the pvchange command:
# pvchange -a N /dev/disk/disk14_p2
134 Troubleshooting LVM
NOTE: On an HP 9000 server, the boot disk is not partitioned so the physical volume refers to the entire disk, not the HP-UX partition. Use the following command:
# pvchange -a N /dev/disk/disk14
3.
Replace the disk.
For the hardware details on how to replace the disk, see the hardware administrator’s guide for the system or disk array.
If the disk is hot-swappable, replace it.
If the disk is not hot-swappable, shut down the system, turn off the power, and replace the disk. Reboot the system. Two problems can occur:
•
If you replaced the disk that you normally boot from, the replacement disk does not contain the information needed by the boot loader. In this case, interrupt the boot process and boot from the mirror boot disk, which is configured as the alternate boot path.
•
If there are only two disks in the root volume group, the system probably fails its quorum check as described in
“Volume Group Activation Failures” (page 111)
. It can panic early in the boot process with the message:
panic: LVM: Configuration failure
In this situation, you must override quorum to boot successfully. Do this by interrupting the boot process and adding the –lq option to the boot command.
For information on the boot process and how to select boot options, see HP-UX System
Administrator's Guide: Configuration Management.
4.
Notify the mass storage subsystem that the disk has been replaced.
If the system was not rebooted to replace the failed disk, then run scsimgr before using the new disk as a replacement for the old disk. For example:
# scsimgr replace_wwid –D /dev/rdisk/disk14
This command allows the storage subsystem to replace the old disk’s LUN World-Wide-Identifier
(WWID) with the new disk’s LUN WWID. The storage subsystem creates a new LUN instance and new device special files for the replacement disk.
5.
Determine the new LUN instance number for the replacement disk.
For example:
# ioscan –m lun
Class I Lun H/W Path Driver S/W State H/W Type Health Description
======================================================================== disk 14 64000/0xfa00/0x0 esdisk NO_HW DEVICE offline HP MSA Vol
/dev/disk/disk14 /dev/rdisk/disk14
/dev/disk/disk14_p1 /dev/rdisk/disk14_p1
/dev/disk/disk14_p2 /dev/rdisk/disk14_p2
/dev/disk/disk14_p3 /dev/rdisk/disk14_p3
...
disk 28 64000/0xfa00/0x1c esdisk CLAIMED DEVICE online HP MSA Vol
0/1/1/1.0x3.0x0
/dev/disk/disk28 /dev/rdisk/disk28
In this example, LUN instance 28 was created for the new disk, with LUN hardware path
64000/0xfa00/0x1c, device special files /dev/disk/disk28 and /dev/rdisk/disk28, at the same lunpath hardware path as the old disk, 0/1/1/1.0x3.0x0. The old LUN instance
14 for the old disk now has no lunpath associated with it.
Disk Troubleshooting and Recovery Procedures 135
NOTE: If the system was rebooted to replace the failed disk, then ioscan –m lun does not display the old disk.
6.
(HP Integrity servers only) Partition the replacement disk.
Partition the disk using the idisk command and a partition description file, and create the partition device files using insf, as described in
“Mirroring the Boot Disk on HP Integrity
7.
Assign the old instance number to the replacement disk.
For example:
# io_redirect_dsf -d /dev/disk/disk14 -n /dev/disk/disk28
This assigns the old LUN instance number (14) to the replacement disk. In addition, the device special files for the new disk are renamed to be consistent with the old LUN instance number.
The following ioscan –m lun output shows the result:
# ioscan –m lun /dev/disk/disk14
Class I Lun H/W Path Driver S/W State H/W Type Health Description
======================================================================== disk 14 64000/0xfa00/0x1c esdisk CLAIMED DEVICE online HP MSA Vol
0/1/1/1.0x3.0x0
/dev/disk/disk14 /dev/rdisk/disk14
/dev/disk/disk14_p1 /dev/rdisk/disk14_p1
/dev/disk/disk14_p2 /dev/rdisk/disk14_p2
/dev/disk/disk14_p3 /dev/rdisk/disk14_p3
The LUN representation of the old disk with LUN hardware path 64000/0xfa00/0x0 was removed. The LUN representation of the new disk with LUN hardware path
64000/0xfa00/0x1c was reassigned from LUN instance 28 to LUN instance 14 and its device special files were renamed as /dev/disk/disk14 and /dev/rdisk/disk14.
8.
Restore LVM configuration information to the new disk.
For example:
# vgcfgrestore -n /dev/vg00 /dev/rdisk/disk14_p2
NOTE: On an HP 9000 server, the boot disk is not partitioned, so the physical volume refers to the entire disk, not the HP-UX partition. Use the following command:
# vgcfgrestore -n /dev/vg00 /dev/rdisk/disk14
9.
Restore LVM access to the disk.
If you did not reboot the system in
Step 2 , “Halt LVM access to the disk,” reattach the disk as
follows:
# pvchange –a y /dev/disk/disk14_p2
On an HP 9000 server, use this command:
# pvchange –a y /dev/disk/disk14
If you did reboot the system, reattach the disk by reactivating the volume group as follows:
# vgchange -a y /dev/vg00
136 Troubleshooting LVM
NOTE: The vgchange command with the -a y option can be run on a volume group that is deactivated or already activated. It attaches all paths for all disks in the volume group and resumes automatically recovering any disks in the volume group that had been offline or any disks in the volume group that were replaced. Therefore, run vgchange only after all work has been completed on all disks and paths in the volume group, and it is necessary to attach them all.
10. Initialize boot information on the disk.
For an HP Integrity server, set up the boot area and update the autoboot file in the disk's EFI partition as described in step 5 and step 6 of
“Mirroring the Boot Disk on HP Integrity Servers”
.
For an HP 9000 server, set up the boot area and update the autoboot file as described in step 4 and step 5 of
“Mirroring the Boot Disk on HP 9000 Servers” (page 90)
.
Replacing an Unmirrored Boot Disk
With the failure of an unmirrored boot disk, you have lost the only copy of information that is required to boot the system. You must reinstall onto the replacement disk, or recover it from an
Ignite-UX backup.
Disk Troubleshooting and Recovery Procedures 137
Step 7: Replacing a Bad Disk (Legacy DSFs)
Follow these steps to replace a bad disk if your system is configured with only legacy DSFs.
NOTE: LVM recommends the use of persistent device special files, because they support a greater variety of load balancing options. For replacing a disk with persistent device special files, see
“Step 6: Replacing a Bad Disk (Persistent DSFs)” (page 129)
To replace a bad disk, follow these steps.
1.
Halt LVM Access to the Disk.
If the disk is not hot-swappable, power off the system to replace it. By shutting down the system, you halt LVM access to the disk, so you can skip this step.
If the disk is hot-swappable, disable user and LVM access to all unmirrored logical volumes.
•
First, disable user access to all unmirrored logical volumes or any mirrored logical volumes without an available and current mirror copy. Halt any application and umount any file systems using these logical volumes. This prevents the applications or file systems from writing inconsistent data over the newly restored replacement disk.
•
After disabling user access to the unmirrored logical volumes, disable LVM access to the disk, as follows:
# pvchange -a N pvname
The following recommendation are intended to maximize system uptime and access to the volume group, but you can use a stronger approach if your data and system availability requirement allows.
•
If pvdisplay shows “PV status” as available, halt LVM access to the disk by removing it from the volume group.
•
If pvdisplay show “PV status” as unavailable, or if pvdisplay fails to print the status, use ioscan to determine if the disk can be accessed at all. If ioscan reports the disk status as NO_HW on all its hardware paths, you can remove the disk. If ioscan shows any other status, halt LVM access to the disk by deactivaing the volume group.
2.
Replace the Faulty Disk
If the disk is hot-swappable, you can replace it without powering down the system. Otherwise, power down the system before replacing the disk. For the hardware details on how to replace the disk, see the hardware administrator’s guide for the system or disk array. If you powered down the system, reboot it normally. The only exception is if you replaced a disk in the root volume group.
•
If you replaced the disk that you normally boot from, the replacement disk does not contain the information needed by the boot loader. If your root disk is mirrored, boot from it by using the alternate boot path. If the root disk was not mirrored, you must reinstall or recover your system.
•
If there are only two disks in the root volume group, the system probably fails its quorum check as described in
“Volume Group Activation Failures” (page 111)
. It can panic early in the boot process with the message:
panic: LVM: Configuration failure
In this situation, you must override quorum to boot successfully. Do this by interrupting the boot process and adding the –lq option to the boot command.
For information on the boot process and how to select boot options, see HP-UX System
Administrator's Guide: Configuration Management.
138 Troubleshooting LVM
3.
Initialize the Disk for LVM
This step copies LVM configuration information onto the disk, and marks it as owned by LVM so it can subsequently be attached to the volume group.
If you replaced a mirror of the root disk on an Integrity server, run the idisk and insf commands as described in
“Mirroring the Boot Disk on HP Integrity Servers” (page 92)
. For
PA-RISC servers or non-root disks, this step is unnecessary.
For any replaced disk, restore LVM configuration information to the disk using the vgcfgrestore command as follows:
# vgcfgrestore -n vgname pvname
NOTE: If the vgcfgrestore command fails to write the original LVM header back to the new disk because a valid LVM configuration backup file (/etc/lvmconf/vgXX.conf[.old]) is missing or corrupted, you must remove the physical volume that is being restored from the volume group (with the vgreduce command) to get a clean configuration.
In these situations the vgcfgrestore command might fail to restore the LVM header, issuing this message:
Mismatch between the backup file and the running kernel
If you are sure that your backup is valid, you can override this check by using the –R option.
To remove a physical volume from a volume group, you must first free it by removing all of the logical extents. If the logical volumes on such a disk are not mirrored, the data is lost anyway. If it is mirrored, you must reduce the mirror before removing the physical volume.
4.
Re-Enable LVM Access to the Disk.
This step re-attaches the disk, as follows
# pvchange -a y pvname
5.
Restore Lost Data to the Disk
This final step can be a straightforward re-synchronization for mirrored configurations, or a recovery of data from backup media.
•
If a mirror of the root disk was replaced, initialize its boot information as follows:
◦ For an Integrity server, follow steps 5, 6, and 8 in
“Mirroring the Boot Disk on HP
◦ For a PA-RISC server, follow steps 4, 5, and 7 in
“Mirroring the Boot Disk on HP
•
If all the data on the replaced disk was mirrored, you do not have to do anything; LVM automatically synchronizes the data on the disk with the other mirror copies of the data.
•
If the disk contained any unmirrored logical volumes (or mirrored logical volumes that did not have a current copy on the system), restore the data from backup, mount the file systems, and restart any applications you halted in Step 1.
Reporting Problems
If you are unable to solve a problem with LVM, follow these steps:
1.
Read the HP-UX Logical Volume Manager and MirrorDisk/UX Release Notes to see if the problem is known. If it is, follow the solution offered to solve the problem.
2.
Determine if the product is still under warranty or if your company purchased support services for the product. Your operations manager can supply you with the necessary information.
3.
Access http://www.itrc.hp.com and search the technical knowledge databases to determine if the problem you are experiencing has been reported already. The type of documentation and resources you have access to depend on your level of entitlement.
Reporting Problems 139
NOTE: The ITRC resource forums at http://www.itrc.hp.com offer peer-to-peer support to solve problems and are free to users after registration.
If this is a new problem or if you need additional help, log your problem with the HP Response
Center, either online through the support case manager at http://www.itrc.hp.com, or by calling HP Support. If your warranty has expired or if you do not have a valid support contract for your product, you can still obtain support services for a fee, based on the amount of time and material required to solve your problem.
4.
If you are asked to supply any information pertaining to the problem, gather the requested information and submit it.
140 Troubleshooting LVM
5 Support and Other Resources
New and Changed Information in This Edition
The eighth edition of HP-UX System Administrator's Guide: Logical Volume Management addresses the following new topics:
•
Added information about converting cDSFs back to their corresponding persistent DSFs, in
.
•
Provided new information on LVM I/O timeout parameters, see
and
“LVM I/O Timeout Parameters” (page 161) .
•
Added error message information for vgmodify in
“Warning and Error Messages” (page 163)
.
•
Added error message and recommendation for failure in deletion of snapshot logical volume device, see
“Warning and Error Messages” (page 163)
.
About this Series
The HP-UX System Administrator’s Guide documents the core set of tasks (and associated concepts) necessary to administer systems running HP-UX 11i Version 3.
The HP-UX System Administrator’s Guide is a set of documents comprised of the following volumes:
Overview
Provides a high-level view of HP-UX 11i, its components, and how they relate to each other.
Configuration Management
Logical Volume Management
Describes many of the tasks you must perform to configure and customize system settings and the behavior of subsystems.
Documents how to configure physical volumes, volume groups, and logical volumes using the HP Logical Volume
Manager (LVM).
Security Management
Routine Management Tasks
Documents the data and system security features of HP-UX
11i.
Documents many of the ongoing tasks you must perform to keep your system running smoothly.
Typographic Conventions
This document uses the following typographical conventions:
%
, $, or # A percent sign represents the C shell system prompt. A dollar sign represents the system prompt for the Bourne, Korn, and
POSIX shells. A number sign represents the superuser prompt.
audit(5)
Command
A manpage. The manpage name is audit, and it is located in Section 5.
A command name or qualified command phrase.
Computer output
Ctrl+x
Document Title
ENVIRONMENT VARIABLE
ERROR NAME
Text displayed by the computer.
A key sequence. A sequence such as Ctrl+x indicates that you must hold down the key labeled Ctrl while you press another key or mouse button.
The title of a document. On the web and on the Instant
Information media, it may be a hot link to the document itself.
The name of an environment variable, for example, PATH.
The name of an error, usually returned in the errno variable.
New and Changed Information in This Edition 141
Key
Term
User input
Variable
or Replaceable
-chars
-word
[ ]
{ }
...
The name of a keyboard key. Return and Enter both refer to the same key.
The defined use of an important word or phrase.
Commands and other text that you type.
The name of a placeholder in a command, function, or other syntax display that you replace with an actual value.
One or more grouped command options, such as -ikx. The
chars are usually a string of literal characters that each represent a specific option. For example, the entry -ikx is equivalent to the individual options -i, -k, and -x. The plus character (+) is sometimes used as an option prefix.
A single command option, such as -help. The word is a literal keyword. The difference from -chars is usually obvious and is clarified in an Options description. The plus character
(+) and the double hyphen (--) are sometimes used as option prefixes.
The bracket metacharacters enclose optional content. If the contents are a list separated by |, you choose one of the items.
The brace metacharacters enclose required content. If the contents are a list separated by |, you must choose one of the items.
The preceding element can be repeated an arbitrary number of times. Ellipsis is sometimes used to indicate omitted items in a range.
Indicates the continuation of a code example.
|
WARNING
CAUTION
IMPORTANT
NOTE
Separates items in a list of choices.
A warning calls attention to important information that if not understood or followed will result in personal injury or nonrecoverable system problems.
A caution calls attention to important information that if not understood or followed will result in data loss, data corruption, or damage to hardware or software.
This alert provides essential information to explain a concept or to complete a task.
A note contains additional information to emphasize or supplement important points of the main text.
Examples and Shells
This document describes practices used by the system administrator. Since the root user (superuser) is required to use the POSIX shell /sbin/sh, all command examples use that shell. The POSIX shell is defined in sh-posix(1). For information on other shells, see the Shells User’s Guide and
sh(1).
142 Support and Other Resources
Related Information
HP-UX technical documentation can be found on HP's documentation website at http:// www.hp.com/go/hpux-core-docs.
In particular, LVM documentation is provided on this web page:http://www.hp.com/go/ hpux-LVM-VxVM-docs. See the HP-UX Logical Volume Manager and Mirror Disk/UX Release Notes for information about new features and defect fixes on each release. In addition, the following white papers are available:
•
LVM Migration from Legacy to Agile Naming Model
•
LVM Online Disk Replacement (LVM OLR)
•
LVM Volume Group Quiesce/Resume
•
SLVM Online Reconfiguration
•
Using the vgmodify Command to Perform LVM Volume Group Dynamic LUN Expansion (DLE) and Contraction (DLC)
•
LVM Snapshot Logical Volumes
For detailed description of each LVM command and their options, see the LVM manpages that are installed with the LVM product, accessible via the man command. The manpage are also published on http://www.hp.com/go/hpux-clickable-manpages
Finding HP-UX Information
The following table outlines where to find system administration information for HP-UX. This table does not include information for specific products.
Table 10 Finding HP-UX Information
If you need to Refer To
Find out:
• What has changed in HP-UX releases
• The contents of the
Operating
Environments
• Firmware requirements and supported systems for a specific release
The HP-UX 11i Release Notes specific to your version of HP-UX.
Located at .
• HP Instant Information media
• HP-UX Technical Documentation website at:http://www.hp.com/go/ hpux-core-docs
Install or update
HP-UX
Administer an HP-UX system
• Read Before Installing or Updating to HP-UX
• HP-UX 11i Installation and Update Guide
• Media Kit (supplied with the
Operating Environment)
• HP Instant Information media
• HP-UX Technical Documentation website at:http://www.hp.com/go/ hpux-core-docs
Releases beginning with HP-UX 11i Version 3:
• HP-UX System Administrator’s Guide (a multivolume set)
Other sources of system administration information:
• nPartition Administrator's Guide
• Planning Superdome Configuration White Paper
• HP Superdome 2 Partitioning Administrator Guide
• HP Instant Information media
• HP-UX Technical Documentation website at:http://www.hp.com/go/ hpux-core-docs
Related Information 143
HP-UX 11i Release Names and Operating System Version Identifiers
With HP-UX 11i, HP delivers a highly available, secure, and manageable operating system that meets the demands of end-to-end Internet-critical computing. HP-UX 11i supports enterprise, mission-critical, and technical computing environments. HP-UX 11i is available on both HP 9000 systems and HP Integrity systems.
Each HP-UX 11i release has an associated release name and release identifier. The uname command with the -r option returns the release identifier.
shows the releases available for HP-UX 11i.
Table 11 HP-UX 11i Releases
OS Version Identifier
B.11.11
B.11.23
B.11.23.0409
B.11.31
Release Name
HP-UX 11i Version 1
HP-UX 11i Version 2
HP-UX 11i Version 2
September 2004 Update
HP-UX 11i Version 3
Supported Processor Architecture
HP 9000
Integrity
HP 9000 and Integrity
HP 9000 and Integrity
For information on supported systems and processor architecture for various versions of HP-UX 11i, see the HP-UX 11i system release notes specific to your version of HP-UX.
Determining Your System Version
The uname, model, and swlist commands can help you determine information about your system, including its hardware type, machine model, operating system version, and operating environment update status. See uname(1), model(1), and swlist(1M).
For OS naming conventions, see
“HP-UX 11i Release Names and Operating System Version
Table 12 OS Version, System Architecture, and Machine Model
Topic
OS Version
Architecture
Command
$ uname -r
$ uname -m
Sample Output
B.11.31
1 ia64
2
9000/800
2
Machine Model
$ model
3 ia64 hp server rx5670
9000/800/S16K-A
Operating Environment
$ swlist HPUX*OE* # HPUX11i-OE-MC B.11.31 HP-UX Mission
Critical Operating Environment
1
OS Version.Update
$ swlist HPUX*OE* # HPUX11i-TCOE B.11.23.0409 HP-UX
Technical Computing OE Component
1
1 HP-UX 11i OS version identifiers have the form B.11.23 or B.11.23.0409, where B.11.23 is the OS version and
0409 is the year-month of the operating environment (OE) update.
2 ia64
= Integrity. All others = HP 9000.
3 The getconf MACHINE_MODEL command gives the same output. See getconf(1).
Publication History
The document printing date and part number indicate the document’s current edition. The printing date changes when a new edition is printed. Minor changes can be made at reprint without changing the printing date. The document part number changes when extensive changes are made.
144 Support and Other Resources
Document updates can be issued between editions to correct errors or document product changes.
To ensure that you receive the updated or new editions, subscribe to the appropriate product support service. See your HP sales representative for details. You can find the latest version of this document online at: http://www.hp.com/go/hpux-LVM-VxVM-docs .
Publication Date Manufacturing Part
Number
5991-6481
5992-3385
5992-4589
5992-6576
B3921–90000
B3921–90014
B3921–90038
B3921–90053
Supported Operating
Systems
HP-UX
HP-UX
HP-UX
Supported Versions
HP-UX 11i Version 3
HP-UX 11i Version 3
HP-UX 11i Version 3
HP-UX
HP-UX
HP-UX
HP-UX
HP-UX
HP-UX 11i Version 3
HP-UX 11i Version 3
HP-UX 11i Version 3
HP-UX 11i Version 3
HP-UX 11i Version 3
6
7
4
5
8
1
2
Edition
Number
3
February 2007
March 2008
September 2008
September 2009
March 2010
September 2010
March 2011
September 2011
NOTE: The volumes in the HP-UX System Administrator’s Guide can be updated independently.
Therefore, the latest versions of the volumes in the set can vary with time and with respect to each other. The latest versions of each volume are available at http://www.hp.com/go/hpux-core-docs.
HP Insight Remote Support Software
HP strongly recommends that you install HP Insight Remote Support software to complete the installation or upgrade of your product and to enable enhanced delivery of your HP Warranty,
HP Care Pack Service or HP contractual support agreement. HP Insight Remote Support supplements your monitoring, 24x7 to ensure maximum system availability by providing intelligent event diagnosis, and automatic, secure submission of hardware event notifications to HP, which will initiate a fast and accurate resolution, based on your product’s service level. Notifications may be sent to your authorized HP Channel Partner for on-site service, if configured and available in your country. The software is available in two variants:
•
HP Insight Remote Support Standard: This software supports server and storage devices and is optimized for environments with 1-50 servers. Ideal for customers who can benefit from proactive notification, but do not need proactive service delivery and integration with a management platform.
•
HP Insight Remote Support Advanced: This software provides comprehensive remote monitoring and proactive service support for nearly all HP servers, storage, network, and SAN environments, plus selected non-HP servers that have a support obligation with HP. It is integrated with HP Systems Insight Manager. A dedicated server is recommended to host both
HP Systems Insight Manager and HP Insight Remote Support Advanced.
Details for both versions are available at: http://www.hp.com/go/insightremotesupport
To download the software, go to Software Depot: http://www.software.hp.com
Select Insight Remote Support from the menu on the right.
HP Insight Remote Support Software 145
HP Encourages Your Comments
HP encourages your comments concerning this document. We are committed to providing documentation that meets your needs. Send any errors found, suggestions for improvement, or compliments to: http://www.hp.com/bizsupport/feedback/ww/webfeedback.html
Include the document title, manufacturing part number, and any comment, error found, or suggestion for improvement you have concerning this document.
146 Support and Other Resources
A LVM Specifications and Limitations
This appendix discusses LVM product specifications.
NOTE: Do not infer that a system configured to these limits is automatically usable.
Table 13 Volume Group Version Maximums
Version 1.0
Volume Groups
Maximum data on a single HP-UX system
128 PB
Maximum number of volume groups on a system
256
Maximum number of physical volumes in a volume group
255
Maximum number of logical volumes in a volume group
255
Maximum size of a physical volume
2 TB
Maximum size of a volume group
Maximum size of a logical volume
Maximum size of a physical extent
Maximum size of a stripe
510 TB
16 TB
256 MB
32 MB
Maximum number of stripes
255
Maximum number of logical extents per logical volume
65535
Maximum number of physical extents per physical volume
65535
Maximum number of mirror copies
(MirrorDisk/UX product required)
2
Maximum number of snapshots per LV
Not supported
Maximum size for the unit of unsharing between logical volume and its snapshot
Not supported
Maximum snapshot capacity per VG
Not supported
Version 2.0
Volume Groups
1024 PB
512
1
511
511
16 TB
2048 TB
256 TB
256 MB
256 MB
511
33554432
16777216
5
Not supported
Not supported
Not supported
Version 2.1
Volume Groups
1024 PB
2048
1
2048
2047
16 TB
2048 TB
256 TB
256 MB
256 MB
511
33554432
16777216
5
Not Supported
Not Supported
Not Supported
Version 2.2
Volume Groups
1024 PB
2048
1
2048
2047
2
16 TB
2048 TB
256 TB
256 MB
256 MB
511
33554432
16777216
5
255
4M
Maximum VG capacity
147
1 The limit of 2048 volume groups is shared among Version 2.x volume groups. Volume groups of Versions 2.x can be created with volume group numbers ranging from 0-2047. However, the maximum number of Version 2.0 volume groups that can be created is 512.
2 For volume group Version 2.2 or higher, the total number of logical volumes includes normal logical volumes as well as snapshot logical volumes.
Table 14 Version 1.0 Volume Group Limits
Default Value Maximum Value Parameter Command to Set/Change
Parameter n/a Number of volume groups on a system
Number of physical volumes in a volume group vgcreate –p max_pv vgmodify –p max_pv
0
1
Minimum Value n/a
16
256
255
Number of logical volumes in a volume group vgcreate –l max_lv vgmodify –l max_lv
Size of a physical volume
Size of a logical volume pvcreate –s pv_size lvcreate –L lv_size lvextend –L lv_size
1
1 PE
0
255
LUN Capacity
0
255
2 TB
16 TB
Size of a physical extent
Size of a stripe vgcreate –s pe_size lvcreate –l
stripe_size
lvcreate –i stripes
1 MB
4 KB
2
4 MB
8 KB
256 MB
32 MB
Number of stripes n/a Number of
PVs in VG
65535 Number of logical extents per logical volume lvcreate –l max_le lvextend –l max_le
Number of physical extents per physical volume vgcreate –e max_pe vgmodify –e max_pe
0
1
0
1016
1
65535
Number of mirror copies
(MirrorDisk/UX product required) lvcreate –m copies lvextend –m copies
0 0 2
1 If more than 1016 extents are necessary to access all of the first physical volume in the volume group, vgcreate increases the default value to the size of the first physical volume divided by the physical extent size.
148 LVM Specifications and Limitations
Table 15 Version 2.x Volume Group Limits
Parameter Command to Set/Change
Parameter n/a Number of volume groups on a system
Number of physical volumes in a volume group n/a
0
Minimum Value Default Value n/a
Maximum Value
2048
1
Number of logical volumes in a volume group n/a
511
511
511 (2.0)
2048 (2.1, 2.2)
511 (2.0)
2047 (2.1, 2.2) n/a
511 (2.0)
2048 (2.1, 2.2)
511 (2.0)
2047 (2.1, 2.2)
2
2 PB Size of a volume group
Size of a physical volume
Size of a logical volume vgcreate –S
max_vgsize
pvcreate –s pv_size lvcreate –L lv_size lvextend –L lv_size
1 MB
1 PE
0
3
LUN Capacity
0
16 TB
256 TB
Size of a physical extent
Size of a stripe
Number of stripes
Number of logical extents per logical volume vgcreate –s pe_size lvcreate –l
stripe_size
lvcreate –i stripes lvcreate –l max_le lvextend –l max_le
1 MB
4 KB
2
0 n/a n/a n/a
0
256 MB
256 MB
511
33554432
Number of physical extents per physical volume n/a 1 LUN Capacity
÷ PE Size
16777216
Number of snapshots per logical volume (for volume group Version 2.2 and higher only) n/a 0 0 255
Size of unshare unit for snapshots (for volume group
Version 2.2 and higher only) vgcreate -U
unshare_unit
Maximum snapshot capacity
(for volume group Version
2.2 and higher only) n/a
512KB
max_vgsize
1024KB
max_vgsize
4096KB
max_vgsize
Number of mirror copies
(MirrorDisk/UX product required) lvcreate –m copies lvextend –m copies
0 0 5
1 The limit of 2048 volume groups is shared among Version 2.x volume groups. Volume groups of Versions 2.x can be created with volume group numbers ranging from 0-2047. However, the maximum number of Version 2.0 volume groups that can be created is 512.
2 For volume group Version 2.2 or higher, the total number of logical volume includes normal logical volumes as well as snapshot logical volumes.
3 If the total size of the specified physical volumes is larger than max_vgsize, vgcreate adjusts the minimum volume group size to the total size.
149
Determining LVM’s Maximum Limits on a System
The March 2008 update to HP-UX 11i v3 (11.31) introduced a new command that enables the system administrator to determine the maximum LVM limits supported on the target system for a given volume group version. The lvmadm command displays the implemented limits for Version
1.0 and Version 2.x volume groups. It is impossible to create a volume group that exceeds these limits.
Example
# lvmadm -t
--- LVM Limits ---
VG Version 1.0
Max VG Size (Tbytes) 510
Max LV Size (Tbytes) 16
Max PV Size (Tbytes) 2
Max VGs 256
Max LVs 255
Max PVs 255
Max Mirrors 2
Max Stripes 255
Max Stripe Size (Kbytes) 32768
Max LXs per LV 65535
Max PXs per PV 65535
Max Extent Size (Mbytes) 256
VG Version 2.0
Max VG Size (Tbytes) 2048
Max LV Size (Tbytes) 256
Max PV Size (Tbytes) 16
Max VGs 512
Max LVs 511
Max PVs 511
Max Mirrors 5
Max Stripes 511
Max Stripe Size (Kbytes) 262144
Max LXs per LV 33554432
Max PXs per PV 16777216
Max Extent Size (Mbytes) 256
VG Version 2.1
Max VG Size (Tbytes) 2048
Max LV Size (Tbytes) 256
Max PV Size (Tbytes) 16
Max VGs 2048
Max LVs 2047
Max PVs 2048
Max Mirrors 5
Max Stripes 511
Max Stripe Size (Kbytes) 262144
Max LXs per LV 33554432
Max PXs per PV 16777216
Max Extent Size (Mbytes) 256
VG Version 2.2
Max VG Size (Tbytes) 2048
Max LV Size (Tbytes) 256
Max PV Size (Tbytes) 16
Max VGs 2048
Max LVs 2047
Max PVs 2048
Max Mirrors 5
Max Stripes 511
Max Stripe Size (Kbytes) 262144
Max LXs per LV 33554432
150 LVM Specifications and Limitations
Max PXs per PV 16777216
Max Extent Size (Mbytes) 256
Min Unshare unit (Kbytes) 512
Max Unshare unit (Kbytes) 4096
Max Snapshots per LV 255
Determining LVM’s Maximum Limits on a System 151
B LVM Command Summary
This appendix contains a summary of the LVM commands and descriptions of their use.
Table 16 LVM Command Summary
Command extendfs
Description and Example
Extends a file system:
# extendfs /dev/vg00/rlvol3 lvmadm lvchange lvcreate lvdisplay lvextend -m lvextend -L lvlnboot lvmerge lvmove lvmpud lvreduce -L lvreduce -m lvremove lvrmboot lvsplit lvsync
Displays the limits associated with a volume group version:
# lvmadm -t -V 2.0
Changes the characteristics of a logical volume:
# lvchange -t 60 /dev/vg00/lvol3
Creates a logical volume in a volume group:
# lvcreate -L 100 /dev/vg00
Displays information about logical volumes:
# lvdisplay -v /dev/vg00/lvol1
Adds a mirror to a logical volume:
# lvextend -m 1 /dev/vg00/lvol3
Increases the size of a logical volume:
# lvextend -L 120 /dev/vg00/lvol3
Prepares a logical volume to become a root, swap, or dump area:
# lvlnboot -d /dev/vg00/lvol2
Merges split volumes into one logical volume:
# lvmerge /dev/vg00/lvol4b /dev/vg00/lvol4
Migrate a logical volume to new disks:
# lvmove -f newdisks.txt /dev/vg00/lvol2
Daemon to handle online shared LVM reconfiguration, and pre-allocation of extents for space-efficient snapshots:
# lvmpud
Decreases the size of a logical volume:
# lvreduce -L 100 /dev/vg00/lvol3
Decreases the number of mirror copies of a logical volume:
# lvreduce -m 0 /dev/vg00/lvol3
Removes logical volumes from a volume group:
# lvremove /dev/vg00/lvol6
Removes a logical volume link to root, swap, or dump:
# lvrmboot -d /dev/vg00/lvol2
Splits a mirrored logical volume into two logical volumes:
# lvsplit /dev/vg00/lvol4
Synchronizes stale logical volume mirrors:
# lvsync /dev/vg00/lvol1
152 LVM Command Summary
Table 16 LVM Command Summary (continued)
Command pvchange
Description and Example
Changes the characteristics of a physical volume:
# pvchange -a n /dev/disk/disk2 pvck pvcreate pvdisplay pvmove pvremove vgcfgbackup vgcfgrestore vgchange vgchgid vgcdsf vgcreate vgdisplay vgdsf vgextend vgexport vgimport vgmodify vgmove
Performs a consistency check on a physical volume:
# pvck /dev/disk/disk47_p2
Creates a physical volume be to used as part of a volume group:
# pvcreate /dev/rdisk/disk2
Displays information about a physical volume:
# pvdisplay -v /dev/disk/disk2
Moves extents from one physical volume to another:
# pvmove /dev/disk/disk2 /dev/disk/disk3
Removes LVM data structures from a physical volume:
# pvremove /dev/rdisk/disk2
Saves the LVM configuration for a volume group:
# vgcfgbackup vg00
Restores the LVM configuration:
# vgcfgrestore -n /dev/vg00 /dev/rdisk/disk2
Turns a volume group off or on:
# vgchange -a y /dev/vg00
Changes the volume group ID of a physical volume::
# vgchgid /dev/rdisk/disk3
Converts persistent device special files in a volume group to cluster device special files:
# vgcdsf /dev/vg10
Creates a volume group:
# vgcreate /dev/vg01 /dev/disk/disk2 /dev/disk/disk3
Displays information about a volume group:
# vgdisplay -v /dev/vg00
Migrates volume groups from legacy to persistent device files:
# vgdsf
Extends a volume group by adding a physical volume:
# vgextend /dev/vg00 /dev/disk/disk2
Removes a volume group from the system:
# vgexport /dev/vg01
Adds an existing volume group to the system:
# vgimport -v /dev/vg04
Modifies the configuration parameters of a volume group:
# vgmodify -v -t -n -r vg32
Migrates a volume group to different disks:
# vgmove -f diskmap.txt vg10
153
Table 16 LVM Command Summary (continued)
Command vgscan
Description and Example
Scans the system disks for volume groups:
# vgscan -v vgreduce vgremove vgsync vgversion
Reduces a volume group by removing one or more physical volumes from it:
# vgreduce /dev/vg00 /dev/disk/disk2
Removes the definition of a volume group from the system and the disks:
# vgremove /dev/vg00 /dev/disk/disk2
Synchronizes all mirrored logical volumes in the volume group:
# vgsync vg00
Migrates a volume group to a different version:
# vgversion -V 2.1 vg14
154 LVM Command Summary
C Volume Group Provisioning Tips
This appendix contains recommendations for parameters to use when creating your volume groups.
Choosing an Optimal Extent Size for a Version 1.0 Volume Group
When creating a Version 1.0 volume group, the vgcreate command may fail and display a message that the extent size is too small or that the VGRA is too big. In this situation, you must choose a larger extent size and run vgcreate again.
Increasing the extent size increases the data area marked stale when a write to a mirrored logical volume fails. That can increase the time required to resynchronize stale data. Also, more space may be allocated to each logical volume because the space is allocated in units of extent size.
Therefore, the optimal extent size is the smallest value that can be used to successfully create the volume group with the desired configuration parameters.
The minimum extent size for a volume group is calculated using the maximum number of logical volumes (MAXLVs) and physical volumes (MAXPVs) in the volume group and the maximum number of physical extents (MAXPXs) per each physical volume.
For a volume group with bootable physical volumes, the metadata must fit within 768 KB. Therefore, running vgcreate with a set of values for MAXLVs, MAXPVs and MAXPXs that succeed on a volume group without bootable physical volumes may fail on a volume group with bootable physical volumes. In this situation, if you must add a bootable physical volume to a volume group, recreate the volume group by giving lesser values for these arguments. By far the biggest factor in the size of the metadata is the values for MAXPVs and MAXPXs. Alternatively, convert the bootable physical volume to a normal physical volume by running pvcreate on that physical volume without the
–B option and then adding it to the volume group. For a physical volume that is already part of a volume group, you can use vgmodify to change a physical volume from a bootable to a normal physical volume.
Sample Shell Script
The following shell script creates and compiles a small program that displays the minimum extent size for a given volume group:
#!/usr/bin/sh cat << EOF > vgrasize.c
#include <stdio.h>
#define BS 1024 /* Device block Size */
#define roundup(val, rnd) (((val + rnd - 1) / rnd) * rnd) main(int argc, char *argv[])
{
int i, length, lvs, pvs, pxs;
if (argc != 4) {
/* Usage example:
* Maximum LVs in the VG = 255
* Maximum PVs in the VG = 16
* Maximum extents per PV = 2500
*
* $ vgrasize 255 16 2500
*/
printf("USAGE: %s MAXLVs MAXPVs MAXPXs\n", argv[0]);
exit(1);
}
lvs = atoi(argv[1]);
pvs = atoi(argv[2]);
pxs = atoi(argv[3]);
length = 16 + 2 * roundup(2 +
(roundup(36 + ((3 * roundup(pvs, 32)) / 8) +
(roundup(pxs, 8) / 8) * pvs, BS) +
Choosing an Optimal Extent Size for a Version 1.0 Volume Group 155
roundup(16 * lvs, BS) +
roundup(16 + 4 * pxs, BS) * pvs) / BS, 8);
if (length > 768) {
printf("Warning: A bootable PV cannot be added to a VG \n"
"created with the specified argument values. \n"
"The metadata size %d Kbytes, must be less \n"
"than 768 Kbytes.\n"
"If the intention is not to have a boot disk in this \n"
"VG then do not use '-B' option during pvcreate(1M) \n"
"for the PVs to be part of this VG. \n", length);
}
length = roundup(length, 1024) / 1024;
if (length > 256 ) {
printf("Cannot configure a VG with the maximum values"
" for LVs, PVs and PXs\n");
exit(1);
}
for (i = 1; i < length ; i = i << 1) { }
printf("\nMinimum extent size for this configuration = %d MB\n", i);
exit(0);
}
EOF make vgrasize
Choosing an Optimal Extent Size for a Version 2.x Volume Group
Like Version 1.0 Volume Groups, there is a relationship between extent size and maximum volume group size. There is also a limitation on the number of extents an individual volume group can contain. To determine the proper size, the vgcreate command has a new –E option. This option displays the maximum volume group size based on the given physical extent size or minimum physical extent size based on the maximum volume group size.
Example
After you know the VG size you want to provision for, use vgcreate with the –E option to determine the minimum extent size required to achieve it.
What is the minimum extent size to provision a 2.0 VG for 1 PB?
# vgcreate -V 2.0 -E -S 1p
Max_VG_size=1p:extent_size=32m
What is the maximum 2.0 volume group size with an extent size of 16MB?
#vgcreate -V 2.0 -E -s 16
Max_VG_size=512t:extent_size=16m
What is the minimum extent size to provision a 2.1 VG for 2 PB?
# vgcreate -V 2.1 -E -S 2p
Max_VG_size=2p:extent_size=64m
What is the maximum 2.1 volume group size with an extent size of 32MB?
# vgcreate -V 2.1 -E -s 32
Max_VG_size=1p:extent_size=32m
156 Volume Group Provisioning Tips
D Striped and Mirrored Logical Volumes
This appendix provides more details on striped and mirrored logical volumes. It describes the difference between standard hardware-based RAID and LVM implementation of RAID.
Summary of Hardware Raid Configuration
RAID 0, commonly referred to as striping, refers to the segmentation of logical sequences of data across disks. RAID 1, commonly referred to as mirroring, refers to creating exact copies of logical sequences of data. When implemented in a device hardware, RAID 10 (or RAID 1+0) and RAID
01 (or RAID 0+1) are nested RAID levels. The difference between RAID 0+1 and RAID 1+0 is the location of each RAID system: RAID 0+1 is a mirror of stripes whereas RAID 1+0 is a stripe of mirrors.
shows the RAID 10 and RAID 01 configurations (A1, A2...Ax are stripe chunks of a logical volume).
With a hardware-based RAID 10 configuration, I/O operations are striped first then each strip is mirrored. With hardware-based RAID 01, I/Os are mirrored first then striped. RAID 10 and RAID
01 can have the same physical disk layout.
Figure 6 Hardware Configuration: Raid 10 and Raid 01
The advantages of hardware-based RAID 10 over RAID 01:
•
When one disk fails and is replaced, only the amount of data on this disk needs to be copied or re- synchronized.
•
RAID 10 is more tolerant to multiple disk failures before data becomes unavailable.
The advantages of hardware-based RAID 01 over RAID 10:
•
Simpler to configure striped volumes and then extend mirroring.
•
Able to split the mirror copy and have two usable volume sets
LVM Implementation of RAID Levels in HP-UX
LVM implementation of RAID management is different from the hardware based solutions because it does not nest the RAID levels, but processes them simultaneously. Typically with hardware solutions, you create a LUN with a RAID level and the RAID functions are stacked. LVM provides more flexibility on how logical volumes are created amongst a set of disks as compared to hardware solutions.
LVM allocates the physical extents for striped and mirrored logical volumes in sets of stripe width multiplied by the number of copies of the data. For example, if the logical volume is 1-way mirrored and striped across two disks, extents are allocated to the logical volume, four at a time. LVM enforces that the physical extents of a single set are from different physical volumes. Within this
Summary of Hardware Raid Configuration 157
set, the logical extents are stripped and mirrored to obtain the data layout displayed in
.
Striping and mirroring in LVM combines the advantages of the hardware implementation of RAID
1+0 and RAID 0+1, and provides the following benefits:
•
Better write performance. Write operations take place in parallel and each physical write operation is directed to a different physical volume.
•
Excellent performance for read. Even in the case where several disks are out of service, the read of a stripe can be done in parallel on different physical volumes with one I/O operation per physical volume.
•
High availability of data. With multiple copies of the user data residing on different physical volumes, LVM avoids single point of failure ensuring high availability.
LVM Striped and Mirrored Logical Volume Configuration
You can create a new striped and mirrored logical volume from scratch, or extend (add mirror to) an existing striped logical volume. With the use of physical volume groups (PVGs), mirroring and striping can be directed to specific physical volumes. Without the constraint created by the nesting of levels in hardware based RAID solutions, LVM is combining the striping and mirroring processing, which allows LVM to provide the best of both RAID 10 and RAID 01.
To create a pure RAID 10, ensure that the physical volumes have enough extents in terms of size and stripe width to accommodate the logical volume. Otherwise, LVM optimizes the extent allocation to enable you to create a striped and mirrored logical volume as long as there are enough free extents in the volume group. The logical volume layout then uses a slight variation of RAID 10 and all the benefits of RAID 10 are retained. For example,
shows a volume group with seven physical volumes and a logical volume striped across three disks with one mirror copy.
Figure 7 Example of LVM's Implementation of Raid 10 Variation
If the first physical volume used in the creation has enough extents (size of LV/3) to create RAID
10, only six physical volumes are used, resulting in a strict RAID 1 0 configuration. But if one of the physical volumes, for example PV0, does not have enough free extents, LVM uses another physical volume, PV1, to complete the operation. PV0 was short by two extents so two extents were allocated from PV1. LVM created the logical volume using seven physical volumes resulting in a slight variation of RAID 10.
You can extend your existing striped logical volumes to a striped and mirrored configuration easily, using the lvextend command to add mirrors. You cannot convert existing mirrored logical volumes to a striped and mirrored configuration. You can create any new logical volumes with striped and mirrored configuration as shown in
.
Examples
Use any of the following procedures to create a striped and mirrored logical volume:
•
To create a logical volume of size 90MB striped across two physical volumes with one mirror copy and stripe size of 64 KB, enter:
#lvcreate -L 90 -i 2 -I 64 -m 1 /dev/vgtest
158 Striped and Mirrored Logical Volumes
NOTE: Striping with mirroring always uses strict allocation policies where copies of data do not exist on the same physical disk. This results in a configuration similar to the RAID 01 as illustrated in
•
To create a logical volume of size 90MB striped across two physical volumes with one mirror copy and stripe size of 64 KB and to create the mirror copies on specific disks ( configuration equivalent to RAID 01 as illustrated in
#lvcreate -L 90 -i 2 -I 64 /dev/vgtest
#lvextend -m 1 /dev/vgtest/lvol1 /dev/disk/disk3 /dev/disk/disk4
Contents of /etc/lvmpvg
VG /dev/vgtest
PVG PVG0
/dev/disk/disk1
/dev/disk/disk2
PVG PVG1
/dev/disk/disk3
/dev/disk/disk4
•
Adding a mirror to existing striped logical volumes.
The existing logical volume has the striped property as shown by the lvdisplay output:
# lvdisplay /dev/vgtest/lvol1
--- Logical volumes ---
LV Name /dev/vgtest/lvol1
VG Name /dev/vgtest
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule striped
LV Size (Mbytes) 1024
Current LE 256
Allocated PE 256
Stripes 2
Stripe Size (Kbytes) 64
Bad block on
Allocation strict
IO Timeout (Seconds) default
To get a striped and mirrored configuration, extend the logical volume as follows:
# lvextend -m 1 /dev/vgtest/lvol1
Note that the volume group must have enough physical volumes and extents to accommodate the mirror copy.
Now the lvdisplay output shows the logical volume is striped and mirrored:
# lvdisplay /dev/vgtest/lvol1
--- Logical volumes ---
LV Name /dev/vgtest/lvol1
VG Name /dev/vgtest
LV Permission read/write
LV Status available/syncd
Mirror copies 1
Consistency Recovery MWC
Schedule striped
LV Size (Mbytes) 1024
Current LE 256
Allocated PE 256
Stripes 2
Stripe Size (Kbytes) 64
Bad block on
Allocation strict
IO Timeout (Seconds) default
LVM Striped and Mirrored Logical Volume Configuration 159
Compatibility Note
Releases prior to HP-UX 11i v3 only support striped or mirrored logical volumes and do not support combination of striped and mirrored logical volumes. If a logical volume using simultaneous mirroring and striping is created on HP-UX 11i v3, attempts to import or activate its associated volume group fails on a previous HP-UX release.
To import the volume group with striped and mirrored logical volume to releases prior to HP-UX
11i v3, you must remove the incompatible logical volumes or reduce them to no mirrors.
NOTE: Striped and mirrored logical volume is supported on HP-UX 11i v2 with the PHCO_36744,
PHKL_36745 and PHCO_36746 patches. With these patches or superseding patches installed on a HP-UX 11i v2 system, you can successfully import and activate a volume group with striped and mirrored logical volume created on HP-UX 11i v3.
160 Striped and Mirrored Logical Volumes
E LVM I/O Timeout Parameters
When LVM receives an I/O to a logical volume, it converts this logical I/O to physical I/Os to one or more physical volumes from which the logical volume is allocated. There are two LVM timeout values which affect this operation:
•
Logical volume timeout (LV timeout).
•
Physical volume timeout (PV timeout).
Logical Volume Timeout (LV timeout)
LV timeout controls how long LVM retries a logical I/O after a recoverable physical I/O error.
LVM timeout can be configured for a specific logical volume using lvchange. See the lvchange(1M) manpage for details. Also, note the following:
•
The default LV timeout is zero which means infinite timeout to retry physical I/Os with recoverable errors.
•
If the LV timeout is changed, it should be kept greater than or equal to the PV timeout.
•
Set higher LV timeout for greater I/O resiliency. Set lower LV timeout for faster I/O failure detection (which, in turn, facilitates faster failover).
Physical Volume Timeout (PV timeout)
PV timeout is the time budget set by LVM for each physical I/O originating from LVM. The mass storage stack underlying LVM manages completion of the physical I/O subject to this timeout, resulting in success or failure for the request.
WARNING!
While mass storage stack strives to ensure the physical I/O completion by this PV timeout budget, there could be situations where the I/O completion exceeds this timeout. It could be due to failures in recovery mechanism of underlying transport layers.
PV timeout can be configured for a specific physical volume using pvchange. See the
pvchange(1M) manpage for details. Also, note the following:
•
With 11i v3, native multi-pathing is enabled by default in mass storage stack. When it is enabled:
◦ For clarity, it is recommended that only agile DSFs and cluster DSFs should be used in
LVM when configuring or adding physical volumes to the volume group. Native multi-pathing will still be in effect even if legacy DSFs are specified and this may cause confusion
◦
PV timeout is the time budget given to mass storage stack for its I/O retries on all of the
PV links to this physical volume. However upon the expiration of this PV timeout for a particular physical I/O, the mass storage stack will return this I/O back to LVM even if not all the PV links have been tried within the duration specified by the given PV timeout value. For example, if PV timeout is 30 seconds and if the physical volume has 3 links, the mass storage stack can utilize at the most 30 seconds to retry any I/O on as many links as possible.
•
The PV timeout can be from 2 seconds to a maximum of 300 seconds. The default timeout, shown by a value of “0”, is 30 seconds. However, to ensure reliable handling of device failure, the driver stack requires a PV timeout of no less than 15 seconds. Using values lower than 15 seconds can lead to false failure detection and possibly longer delays as LVM is immediately recovering from a failure. Ideal PV timeout value for a physical volume depends on several factors including number of links to the physical volume, quality/speed/recovery-time of the transport links, physical volume model/type, and so on.
Logical Volume Timeout (LV timeout) 161
Timeout Differences: 11i v2 and 11i v3
Since native multi-pathing is included in 11i v3 mass storage stack and it is enabled by default, the LVM timeout concepts may vary between 11i v2 and 11i v3 in certain cases.
•
Meaning of PV timeout.
In 11i v2, LVM utilizes the configured PV timeout fully for a particular PV link to which it is set. If there is any I/O failure, LVM will retry the I/O on a next available PV link to the same physical volume with the new PV timeout budget.
But in 11i v3, when native multi-pathing is enabled, the mass storage stack does the I/O retries on all/subset of the available PV links within the single configured PV timeout period.
In spite of this difference, the default PV timeout is retained as 30 seconds in 11i v3 to guarantee backward compatibility.
Care should be taken in selecting an appropriate value for the PV timeout in 11i v3, so that retries may be attempted on all available PV links within the timeout period.
•
Timeout considerations for mirrored LV environment.
With 11i v3, in certain situations, LVM I/Os to a mirrored Logical volume may take longer time to complete (comparing to 11i v2) than the configured LVM LV timeout. It happens when one or more PV links goes offline while write I/Os to a mirrored logical volume are in-progress.
The situation gets worse when DasProvider, SAM or lvlnboot runs while PV link goes offline.
However this situation remains only for some period of time (usually up to transient_secs but could be higher in some cases), until the associated LUNs transitions out of transient state either to online or offline state, after which it is recovered automatically. This could be due to the higher timeout value set in the SCSI tunable transient_secs and path_fail_secs.
If the physical volume has few links underneath, reducing these parameters may result in faster
I/O completion.
transient_secs and path_fail_secs are mass storage stack tunable parameters that can be configured through the scsimgr and scsimgr_esdisk commands. Regardless of these parameter settings, the mass storage stack never holds onto any physical I/O originating from LVM for more than the PV timeout budget. These two parameter settings never replace the PV timeout but control the threshold of a LUN and Lunpath before failing I/Os.
CAUTION: Lowering the parameters transient_secs and path_fail_secs may result in less I/O resiliency.
For more details on these two tunable parameters, see the scsimgr(1M) and scsimgr_esdisk(7) manpages. Also refer to the Path Recovery Policies and Managing Loss of Accessibility to a
LUN sections of the HP-UX 11i v3 Native Multi-Pathing for Mass Storage whitepaper on http:// www.hp.com/go/hpux-core-docs.
NOTE: When you use disks with a single link, such as most internal disks, with 11i v3 you can set SCSI parameters transient_secs and path_fail_secs to the PV timeout value to get similar 11i v2 timeout behavior in 11iv3 for the mirrored LV I/Os.
162 LVM I/O Timeout Parameters
F Warning and Error Messages
This appendix lists some of the warning and error messages reported by LVM. For each message, the cause is described and an action is recommended.
Matching Error Messages to Physical Disks and Volume Groups
Often an error message contains the device number for a device, rather than the device file name.
For example, you might see the following message in /var/adm/syslog/syslog.log:
Asynchronous write failed on LUN (dev=0x3000015)
IO details : blkno : 2345, sector no : 23
To map this error message to a specific disk, search under the /dev directory for a device file with a device number that matches the printed value. More specifically, search for a file whose minor number matches the lower six digits of the number following dev:. The device number in this example is 3000015; its lower six digits are 000015, so search for that value using the following command:
# ll /dev/*dsk | grep 000015 brw-r----- 1 bin sys 3 0x000015 May 26 20:01 disk43 crw-r----- 1 bin sys 23 0x000015 May 26 20:01 disk43
Use the pvdisplay command to determine which volume group contains this physical volume as follows:
# pvdisplay /dev/disk/disk43 | grep "VG Name"
VG Name /dev/vgtest
If the pvdisplay command fails, search for the physical volume in the LVM configuration files
/etc/lvmtab and /etc/lvmtab_p as follows:
# lvmadm -l -V 1.0
--- Version 1.0 volume groups ---
VG Name /dev/vg00
PV Name /dev/disk/disk36_p2
VG Name /dev/vgtest
PV Name /dev/disk/disk43
VG Name /dev/vg03
PV Name /dev/dsk/c2t2d0
If your version of lvmadm does not recognize the –l option, use the strings command as follows:
# strings /etc/lvmtab | more
/dev/vg00
/dev/disk/disk36_p2
/dev/vgtest
/dev/disk/disk43
/dev/vg03
/dev/dsk/c2t2d0
Based on the output of these commands, the error message refers to physical volume /dev/disk/ disk43
, which belongs to volume group vgtest.
Similarly, some LVM error messages in /var/adm/syslog/syslog.log contain the device number for a volume group. For example:
LVM: VG 128 0x002000: Lost quorum.
The major number 128 indicates that this is a Version 2.x volume group. A Version 1.0 volume group has a major number of 64. To map this error message to a volume group, search under the
/dev directory for a volume group device file with a device number that matches the major and minor numbers. In this example, the major number is 128 and the minor number is 0x002000, so search for those value using the following command:
# ll /dev/*/group | grep 128.0x002000
crw-r----- 1 root sys 128 0x002000 Jan 7 08:27 /dev/vgtest2/group
Matching Error Messages to Physical Disks and Volume Groups 163
The example error message refers to the Version 2.x volume group vgtest2.
Messages For All LVM Commands
Message Text
vgcfgbackup: /etc/lvmtab is out of date with the running kernel:
Kernel indicates # disks for "/dev/vgname"; /etc/lvmtab has # disks.
Cannot proceed with backup.
Cause
The number of current physical volumes (Cur PV) and active physical volumes (Act PV) are not the same. Cur PV and Act PV must always agree for the volume group. This error also indicates that /etc/lvmtab or /etc/lvmtab_p, which is used to match physical volumes to a volume group, is out of date with the LVM data structures in memory and on disk.
Recommended Action
Try to locate any missing disks. For each of the disk in the volume group, use ioscan and diskinfo to confirm that the disk is functioning properly.
lvchange(1M)
Message Text
"m": Illegal option.
Cause
The system does not have HP MirrorDisk/UX installed.
Recommended Action
Install HP MirrorDisk/UX.
lvextend(1M)
Message Text
lvextend: Not enough free physical extents available.
Logical volume "/dev/vgname/lvname" could not be extended.
Failure possibly caused by strict allocation policy
Cause
There is not enough space in the volume group to extend the logical volume to the requested size.
This is typically caused by one of the following situations:
1.
There are not enough free physical extents in the volume group. Run vgdisplay to confirm the number of available physical extents, and multiply that number by the extent size to determine the free space in the volume group. For example:
# vgdisplay vg00
--- Volume groups ---
VG Name /dev/vg00
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 10
Open LV 10
Max PV 16
Cur PV 1
Act PV 1
164 Warning and Error Messages
Max PE per PV 4350
VGDA 2
PE Size (Mbytes) 4
Total PE 4340
Alloc PE 3740
Free PE 600
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 1.0
VG Max Size 1082g
VG Max Extents 69248
In this example, the total free space is 600 physical extents of 4 MB, or 2400 MB.
2.
The logical volume is mirrored with a strict allocation policy, and there are not enough extents on a separate disk to comply with the allocation policy. To confirm this, run lvdisplay to determine which disks the logical volume occupies, and then check whether there is sufficient space on the other disks in the volume group.
3.
In a SAN environment, one of the disks was dynamically increased in size. LVM did not detect the asynchronous change in size.
Recommended Action
1.
Choose a smaller size for the logical volume, or add more disk space to the volume group.
2.
Choose a smaller size for the logical volume, or add more disk space to the volume group.
Alternatively, free up space on an available disk using pvmove.
3.
Use the vgmodify command to detect the disk size change and incorporate the new space into the volume group.
Message Text
"m": Illegal option.
Cause
The system does not have HP MirrorDisk/UX installed.
Recommended Action
Install HP MirrorDisk/UX.
lvlnboot(1M)
Message Text
lvlnboot: Unable to configure swap logical volume.
Swap logical volume size beyond the IODC max address.
Cause
The boot disk firmware cannot access the entire range of the swap logical volume. This happens with older host bus adapters when primary swap is configured past 4 GB on the disk.
Recommended Action
Upgrade the system firmware or use a newer host bus adapter that supports block addressing. If neither of these actions succeeds, reduce the size of the primary swap logical volume so that it does not exceed 4 GB.
lvlnboot(1M) 165
pvchange(1M)
Message Text
Unable to detach the path or physical volume via the pathname provided.
Either use pvchange(1M) -a N to detach the PV using an attached path or detach each path to the PV individually using pvchange(1M) –a n
Cause
The specified path is not part of any volume group, because the path has not been successfully attached to the otherwise active volume group it belongs to.
Recommended Action
Check the specified path name to make sure it is correct. If the error occurred while detaching a physical volume, specify a different path. If it is not clear whether any path was attached before, individually detach each path to the physical volume using pvchange with the –a n option.
Message Text
Warning: Detaching a physical volume reduces the availability of data within the logical volumes residing on that disk.
Prior to detaching a physical volume or the last available path to it, verify that there are alternate copies of the data available on other disks in the volume group. If necessary, use pvchange(1M) to reverse this operation.
Cause
This warning is advisory. It is generated whenever a path or physical volume is detached.
Recommended Action
None.
vgcfgbackup(1M)
Message Text
Invalid LVMREC on Physical Volume pvname
Cause
The LVM header on the disk is incorrect. This can happen when an existing LVM disk is overwritten with a command like dd or pvcreate. If the disk is shared between two systems, one system might not be aware that the disk is already in a volume group. The corruption can also be caused by running vgchgid incorrectly when using BC split volumes.
Recommended Action
Restore a known good configuration to the disk using vgcfgrestore. Be sure to use a valid copy dated before the first occurrence of the problem. For example:
# vgcfgrestore –n vgname pvname
vgcfgrestore(1M)
Message Text
Cannot restore Physical Volume pvname
Detach the PV or deactivate the VG, before restoring the PV.
166 Warning and Error Messages
Cause
The vgcfgrestore command was used to initialize a disk that already belongs to an active volume group.
Recommended Action
Detach the physical volume or deactivate the volume group before attempting to restore the physical volume. If the disk may be corrupted, detach the disk and mark it using vgcfgrestore, then attach it again without replacing the disk. This causes LVM to reinitialize the disk and synchronize any mirrored user data mapped there.
vgchange(1M)
Message Text
vgchange: WARNING: The "lvmp" driver is not loaded.
Cause
You are activating a Version 2.x volume group, and the kernel driver for Version 2.x volume groups is not loaded.
Recommended Action
Load the lvmp driver, as follows:
# kcmodule lvmp=best
==> Update the automatic 'backup' configuration first? n
* Future operations will ask whether to update the backup.
* The requested changes have been applied to the currently
running configuration.
Module State Cause Notes lvmp (before) unused loadable, unloadable
(now) loaded best
(next boot) loaded explicit
Message Text
vgchange: Warning: Couldn't attach to the volume group physical volume "pvname":
Illegal byte sequence vgchange: Couldn't activate volume group "vgname":
Quorum not present, or some physical volume(s) are missing.
Cause
You are activating a Version 2.x volume group, and your operating system release does not support
Version 2.x volumes.
Recommended Action
Update your system to the March 2008 release of HP-UX 11i Version 3 or a newer release.
Message Text
Warning: couldn't query physical volume "pvname":
The specified path does not correspond to physical volume attached to this volume group
Couldn't query the list of physical volumes.
Cause
This error has the following possible causes: vgchange(1M) 167
1.
The disk was missing when the volume group was activated, but was later restored. This typically occurs when a system is rebooted or the volume group is activated with a disk missing, uncabled, or powered down.
2.
The disk LVM header was overwritten with the wrong volume group information. If the disk is shared between two systems, one system might not be aware that the disk was already in a volume group. To confirm, check the volume group information using the dump_lvmtab command (available from your HP support representative) and look for inconsistencies. For example:
# dump_lvmtab -s | more
SYSTEM : 0x35c8cf58
TIME : 0x3f9acc69 : Sat Oct 25 15:18:01 2003
FILE : /etc/lvmtab
HEADER : version:0x03e8 vgnum:7
VG[00] VGID:35c8cf58 3dd13164 (@0x00040c) pvnum:2 state:0 /dev/vg00
(00) VGID:35c8cf58 3dd13164 PVID:35c8cf58 3dd13164 /dev/dsk/c0t6d0
(01) VGID:35c8cf58 3dd13164 PVID:35c8cf58 3dda4694 /dev/dsk/c4t6d0
VG[01] VGID:065f303f 3e63f01a (@0x001032) pvnum:92 state:0 /dev/vg01
(00) !VGID:35c8cf58 3f8df316 PVID:065f303f 3e63effa /dev/dsk/c40t0d0
(01) !VGID:35c8cf58 3f8df316 PVID:065f303f 3e63effe /dev/dsk/c40t0d4
(02) !VGID:35c8cf58 3f8df316 PVID:065f303f 3e63f003 /dev/dsk/c40t1d0
...
In this example, the VGIDs for the disks in /dev/vg01 are not consistent; inconsistencies are marked !VGID.
Recommended Action
1.
Use ioscan and diskinfo to confirm that the disk is functioning properly. Reactivate the volume group using the following command:
# vgchange –a y vgname
2.
There are several methods of recovery from this error. If you are not familiar with the commands outlined in the following procedures, contact your HP support representative for assistance.
a.
Restore a known good configuration to the disks using vgcfgrestore. Be sure to use a valid copy dated before the first occurrence of the problem. For example:
# vgcfgrestore –n vgname pvname b.
Recreate the volume group and its logical volumes, restoring the data from the most current backup. See
“Creating a Volume Group” (page 44)
and
.
c.
Export and reimport the volume group, as described in
and
“Importing a Volume Group” (page 58)
. For example:
# vgexport -m vgname.map -v -f vgname.file /dev/vgname
# vgimport -m vgname.map -v -f vgname.file /dev/vgname
Message Text
vgchange: Couldn't set the unique id for volume group "/dev/vgname"
Cause
There are multiple LVM group files with the same minor number.
Recommended Action
List the LVM group files. If there are any duplicate minor numbers, export one of the affected volume groups, optionally create a new group file with a unique minor number, and reimport the volume group. If you are not familiar with this procedure, contact your HP support representative for assistance.
# ll /dev/*/group
# vgexport -m vgname.map -v -f vgname.file /dev/vgname
168 Warning and Error Messages
# mkdir /dev/vgname
# mknod /dev/vgname/group c 64 unique_minor_number
# vgimport -m vgname.map -v -f vgname.file /dev/vgname
vgcreate(1M)
Message Text
vgcreate: "/dev/vgname/group": not a character device.
Cause
The volume group device file does not exist, and this version of the vgcreate command does not automatically create it.
Recommended Action
Create the directory for the volume group and create a group file, as described in
Volume Group Device File” (page 44) .
Message Text
vgcreate: Volume group "/dev/vgname" could not be created:
Error: The physical volume "pvname" contains BDRA.
It cannot be added into volume group "/dev/vgname" because this version does not support bootable disks.
Cause
The physical volume pvname is a bootable disk, and vgname is a Version 2.0 or Version 2.1
volume group. Version 2.0 and 2.1 volume groups do not support bootable physical volumes.
Recommended Action
Use the pvcreate command without the -B option to reinitialize the disk, as described in
“Initializing a Disk for LVM Use” (page 43) . For example:
# pvcreate -f pvname
Use the vgmodify command to convert the disk to a nonbootable disk, as described in
Physical Volume Boot Types” (page 84) . Alternately, use the pvcreate command without the -B
option to reinitialize the disk, as described in
“Initializing a Disk for LVM Use” (page 43)
. For example:
# pvcreate -f pvname
Message Text
vgcreate: Volume group "/dev/vgname" could not be created:
VGRA for the disk is too big for the specified parameters.
Increase the extent size or decrease max_PVs/max_LVs and try again.
Cause
The volume group reserved area (VGRA) at the front of each LVM disk cannot hold all the information about the disks in this volume group. This error typically occurs if you use disks larger than 100
GB.
Recommended Action
Adjust the volume group creation parameters. Use the –s option of the vgcreate command to select an extent size larger than 4 MB, or use the –p option to select a smaller number of physical volumes. For more information on these options, see vgcreate(1M). For recommendations on extent sizes, see
.
vgcreate(1M) 169
vgdisplay(1M)
Message Text
vgdisplay: Couldn't query volume group "/dev/vgname".
Possible error in the Volume Group minor number;
Please check and make sure the group minor number is unique.
vgdisplay: Cannot display volume group "/dev/vgname".
Cause
This error has the following possible causes:
1.
There are multiple LVM group files with the same minor number.
2.
Serviceguard was previously installed on the system and the /dev/slvmvg device file still exists.
Recommended Action
1.
List the LVM group files. If there are any duplicate minor numbers, export one of the affected volume groups, optionally create a new group file with a unique minor number, and reimport the volume group. If you are not familiar with this procedure, contact your HP support representative for assistance.
# ll /dev/*/group
# vgexport -m vgname.map -v -f vgname.file /dev/vgname
# mkdir /dev/vgname
# mknod /dev/vgname/group c 64 unique_minor_number
# vgimport -m vgname.map -v -f vgname.file /dev/vgname
2.
Remove the /dev/slvmvg device file and re-create the /etc/lvmtab and /etc/lvmtab_p files using the following commands:
# rm /dev/slvmvg
# mv /etc/lvmtab /etc/lvmtab.old
# mv /etc/lvmtab_p /etc/lvmtab_p.old
# vgscan –v
Message Text
vgdisplay: /etc/lvmtab: No such file or directory vgdisplay: No volume group name could be read from "/etc/lvmtab".
vgdisplay: /etc/lvmtab: No such file or directory vgdisplay: No volume group name could be read from "/etc/lvmtab".
Cause
One of the LVM configuration files, either /etc/lvmtab or /etc/lvmtab_p, is missing.
Recommended Action
Create the /etc/lvmtab and /etc/lvmtab_p files using the following command:
# vgscan –v
For additional information on the vgscan command and its option, see vgscan(1M).
Message Text
Warning: couldn't query physical volume "pvname":
The specified path does not correspond to physical volume attached to this volume group
Couldn't query the list of physical volumes.
Cause
The possible causes of this error are described under the
error messages.
170 Warning and Error Messages
Recommended Action
See the recommended actions under the
error messages.
vgextend(1M)
Message Text
vgextend: Not enough physical extents per physical volume.
Need: #, Have: #.
Cause
The disk size exceeds the volume group maximum disk size. This limitation is defined when the volume group is created, as a product of the extent size specified with the –s option of vgcreate and the maximum number of physical extents per disk specified with the –e option. Typically, the disk is successfully added to the volume group, but not all of the disk is accessible.
Recommended Action
Use the vgmodify command to adjust the maximum number of physical extents per disk. Alternately, you can re-create the volume group with new values for the –s and –e options.
vgimport(1M)
Message Text
vgimport: "/dev/vgname/group": not a character device.
Cause
The volume group device files do not exist, and this version of the vgimport command does not automatically create them.
Recommended Action
Create the directory for the volume group, and create a group file, as described in
Volume Group Device File” (page 44) .
Message Text
Verification of unique LVM disk id on each disk in the volume group
/dev/vgname failed.
Cause
There are two possible causes for this message:
1.
The vgimport command used the –s option and two or more disks on the system have the same LVM identifier; this can happen when disks are created with BC copy or cloned with dd
.
2.
LVM was unable to read the disk header; this can happen when you create new logical units on a SAN array.
Recommended Action
1.
Use vgimport without the –s option. Alternately, use vgchgid to change the LVM identifiers on copied or cloned disks.
2.
Retry the vgimport command.
vgextend(1M) 171
vgmodify(1M)
Message Text
Error: Cannot reduce max_pv below n+1 when the volume group is activated because the highest pvkey in use is n.
Cause
The command is trying to reduce max_pv below the highest pvkey in use. This is disallowed when a version 1.0 volume group is activated since it requires the compacting of pvkeys .
Recommended Action
Try executing the vgmodify operation with n+1 PVs. The permissible max_pv values can be obtained using the vgmodify -t option (used with and without the -a option).
If max_pv needs to be reduced below n+1, deactivate the volume group before running the vgmodify operation.
vgversion(1M)
Message Text
Error: The Physical Volume pvname has bad blocks relocated on it.
Error: Volume Group version 2.x does not support bad block relocation.
Cause
Version 2.x volume groups cannot handle bad blocks on physical volumes. If any physical volume of a Version 1.0 volume group has relocated bad blocks, vgversion fails the migration.
Recommended Action
This physical volume should be replaced by a new disk. For more information on how to replace a disk, see
“Step 6: Replacing a Bad Disk (Persistent DSFs)” (page 129)
or
Bad Disk (Legacy DSFs)” (page 138)
.
Message Text
Error: Could not find any free minor number for volume group version 2.x
Cause
vgversion could not find a free minor number to create the group file for the volume group because all the minor numbers in the supported range for Version 2.x are used by existing Version
2.x volume groups. This can occur when the maximum supported number of Version 2.x volume groups is already created or when some group files exist, but do not correspond to any existing volume group.
Recommended Action
Determine the number of Version 2.x volume groups configured on the system using lvmadm –l.
If this is less than the maximum supported number of Version 2.x volume groups, identify the group files that do not correspond to any of these volume groups. Delete one of these group files and re-run the vgversion command. If you are not familiar with the procedure of finding an unused group file, contact your HP support representative for assistance.
Message Text
Error: The Physical Volume pvname has the pvkey #, which is not supported by volume group version 2.x
172 Warning and Error Messages
Cause
The pvkey of a physical volume can range between 0 to a value equal to one less than the maximum supported number of physical volumes for a volume group version. If the pvkey of the physical volume is not in this range for the target Version 2.x volume group, vgversion fails the migration.
Recommended Action
1.
Use lvmadm to determine the maximum supported number of physical volumes for the target volume group version.
2.
Use vgcfgrestore –l –v to check if there is any unused pvkey in the range supported by the target volume group version.
3.
If a valid pvkey is found in this range, add a disk to the volume group and verify that this physical volume has a pvkey in the supported range. Use pvmove to move all extents from the physical volume pvname to this new physical volume, so that the physical volume pvname can be removed from the volume group.
4.
If the volume group already contains more than the maximum supported number of physical volumes for the target volume group version, then the migration cannot be achieved.
If you are not familiar with any of the steps mentioned above, contact your HP support representative for assistance.
Message Text
Error: The Logical Volume /dev/vgname/lvname has the lv number #, which is not supported by volume group version 2.x.
Cause
The logical volume number of a logical volume can range between 1 to the maximum supported number of logical volumes for a volume group version. If the logical volume number of the logical volume is not in this range for the target Version 2.x volume group, vgversion fails the migration.
Recommended Action
1.
Use lvmadm to determine the maximum supported number of logical volumes for the target volume group version.
2.
For each logical volume device file in the /dev/vgname directory, determine the logical volume number. (Section
“Device Number Format” (page 15)
describes the format of the logical volume device file.) Based on the volume group version, decode the bits associated with the logical volume number and convert this value to decimal notation.
3.
Check if there is any unused logical volume number in the range supported by the target volume group version. If a valid number is found in this range, create a logical volume with the same properties as that of /dev/vgname/lvname. Copy the entire data from this logical volume to the one created newly, so that the logical volume /dev/vgname/lvname can be removed from the volume group.
4.
If the volume group already contains more than the maximum supported number of logical volumes for the target volume group version, then the migration will fail.
If you are not familiar with any of the steps mentioned above, contact your HP support representative for assistance.
Log Files and Trace Files: /var/adm/syslog/syslog.log
LVM does not have a dedicated log file or trace file. It logs errors and warnings to
/var/adm/syslog/syslog.log
. Below are LVM messages that might appear in this file.
Log Files and Trace Files: /var/adm/syslog/syslog.log
173
Message Text
LVM: Begin: Contiguous LV (VG mmm 0x00n000, LV Number: p) movement:
LVM: End: Contiguous LV (VG mmm 0x00n000, LV Number: p) movement:
Cause
This message is advisory. It is generated whenever the extents of a contiguous logical volume belonging to version 2.x volume group is moved using pvmove. This message is generated beginning with the September 2009 Update.
Recommended Action
None, if both the Begin and End message appear for a particular contiguous LV.
If the End message for a contiguous LV is missing in the syslog file, it probably means that the pvmove operation could have been aborted while moving the extents of the LV in question. In this case, the contiguous LV in question could have its extents laid out in a non-contiguous manner. If so, it is recommended that the user run lvdisplay -v to check if the allocation policy for the
LV is broken. If it is broken, then perform the steps below to make the extents of this LV contiguous:
1.
Change the allocation policy of this LV to default (see lvchange(1M)).
2.
Move the extents such that all the physical extents of the logical volume are contiguous (see
pvmove(1M)).
3.
Change the allocation policy back to contiguous (see lvchange(1M)).
Message Text
LVM: VG mm 0xnn0000:
Data in one or more logical volumes on PV nn 0x0nn000
was lost when the disk was replaced.
This occurred because the disk contained the only copy of the data.
Prior to using these logical volumes, restore the data from backup.
Cause
LVM cannot synchronize the data on a replaced disk automatically, for example, when LVM discovers an unmirrored logical volume residing on a disk that was just replaced.
Recommended Action
Restore the contents of the logical volume from backup.
Message Text
LVM: VG mm 0xnn0000: PVLink nn 0x0nn000 Detached.
Cause:
This message is advisory. It is generated whenever a disk path is detached.
Recommended Action
None.
Message Text
LVM: vg[nn] pv[nn] No valid MCR, resyncing all mirrored MWC LVs on the PV
Cause
This message appears when you import a volume group from a previous release of HP-UX. The format of the MWC changed at HP-UX 11i Version 3, so if the volume group contains mirrored logical volumes using MWC, LVM converts the MWC at import time. It also performs a complete resynchronization of all mirrored logical volumes, which can take substantial time.
174 Warning and Error Messages
Recommended Action
None.
Message Text
LVM: vg 64 0xnnnnnn: Unable to register
for event notification on device 0xnnnnnnnn (1)
Cause
This message can be displayed on the first system boot after upgrading to HP-UX 11i Version 3.
It is a transient message caused by updates to the I/O configuration. Later in the boot process,
LVM registers for event notification again, and succeeds.
Recommended Action
None.
Message Text
LVM: WARNING: Snapshot LV (VG mmm 0x00n000, LV Number: p) threshold value reached.
Please increase the number of pre-allocated extents for this snapshot LV
Cause
These are the possible causes:
1.
This message is generated when the number of extents remaining in a space-efficient snapshot logical volume’s pre-allocated pool falls beyond a certain internally computed threshold. The pre-allocated extents of the space-efficient snapshot are consumed as a result of writes either on it’s successor logical volume on the snapshot tree or on the snapshot itself. This message is displayed so that the user is informed that further unsharing of data between the snapshot and its successors might end up depleting the extents in the pre-allocated pool and lead to the snapshot and its predecessors being marked as inoperative.
2.
Beginning with the HP-UX 11i v3 September 2010 Update, you can enable LVM to automatically increase the number of pre-allocated extents when the threshold is reached. If this feature is enabled, this message will be logged every time LVM tries to increase pre-allocated extents.
Recommended Action
1.
Increase the number of pre-allocated extents for the space-efficient snapshot using the lvextend command to prevent the snapshot from becoming inoperative.
2.
If there is no error reported following this warning message, this message can be ignored. If there is an error, please follow the relevant recommended action for the error. If this error is seen more frequently, you can either increase the number of pre-allocated extends and/or threshold value, as appropriate. Please see the LVM Snapshot Logical Volumes white paper for more details.
Message Text
vmunix: LVM:ERROR: The task to increase the pre-allocated extents could not be posted for this snapshot LV (VG 128 0x000000, LVM Number 3).
Please check if lvmpud is running.
Cause
If the automatic increase of pre-allocated extents is enabled for a space efficient snapshot, the numbers of pre-allocated extents are automatically increased when the threshold value is reached.
The lvmpud daemon must be running for this to succeed. When lvmpud is not running, the above message is logged.
Log Files and Trace Files: /var/adm/syslog/syslog.log
175
Recommended Action
Start the lvmpud daemon. Refer to the
“Managing the lvmpud Daemon” (page 105)
section.
Message Text
vmunix: LVM: ERROR: The task posted for increasing the pre-allocated extents failed for the snapshot LV (VG 128 0x004000, LV Number: 48).
Cause
The above message is logged when LVM fails to increase the pre-allocated extents automatically.
This message should not be seen frequently. If seen frequently, it must be a LVM software or configuration issue.
Recommended Action
Increase the number of pre-allocated extents for the space-efficient snapshot using the lvextend command to prevent the snapshot from becoming inoperative.
Message Text
lvmpud->lvextend[]: LogicalExtentsNumber is not bigger than current setting.
LVM: ERROR: The task posted for increasing the pre-allocated extents failed for the snapshot LV (VG 128 0x004000, LV Number: 48).
Cause
This is a known issue (QXCR1001039721) occurring only in the HP-UX 11i v3 September 2010
Update. This message can be ignored.
Recommended Action
None.
Message Text
LVM: Deletion of snapshot LV device [major: nnn, minor:Oxnnnnnn] failed since there are pending I/Os on the successor LV device [major: nnn, minor:Oxnnnnnn] waiting for one or more offline PVs to come back online. Please make the PVs available and retry.
Or,
LVM: Deletion of snapshot LV device [major: nnn, minor:Oxnnnnnn] failed since there are pending I/Os on the predecessor LV device [major: nnn, minor:Oxnnnnnn] waiting for one or more offline PVs to come back online. Please make the PVs available and retry.
Cause
While deleting a snapshot logical volume, if LVM detects pending I/Os due to unavailability of underlying physical volumes on either the successor or the predecessor logical volumes, LVM will abort the delete operation.
Recommended Action
Make sure that the disk devices being used by the entire snapshot tree (the original logical volume and all of its snapshots) are available and healthy before retrying the delete operation.
176 Warning and Error Messages
Glossary
Agile Addressing The ability to address a LUN with the same device special file regardless of the physical location of the LUN or the number of paths leading to it. In other words, the device special file for a LUN remains the same even if the LUN is moved from one Host Bus Adaptor (HBA) to another, moved from one switch/hub port to another, presented via a different target port to the host, or configured with multiple hardware paths. Also referred to as persistent binding.
Agile View The representation of LUNs using the new agile addressing and persistent DSFs, introduced in
HP-UX 11i v3.
Allocation Policy
Device Special File
(DSF)
Disk Spanning
The LVM allocation policy governing how disk space is distributed to logical volumes and how extents are laid out on an LVM disk. LVM allocates disk space in terms of strict vs. non-strict and contiguous vs. noncontiguous. Strict allocation requires that mirror copies reside on different LVM disks. Contiguous allocation requires that no gaps exist between physical extents on a single disk.
HP-UX applications access peripheral devices such as tape drives, disk drives, and printers via special files in the /dev directory called Device Special Files (DSFs). Device Special Files allow applications to access devices with minimum knowledge of the system's underlying hardware.
Beginning with HP-UX 11i v3, HP-UX supports two types of Device Special Files: legacy and persistent.
The allocation of a logical volume across multiple disks, allowing the volume size to exceed the size of a single disk.
Hardware Path
I/O Channel
Separation
Legacy Device
Special Files (DSFs)
Legacy View
As opposed to the physical path-specific lunpath, the LUN hardware path presents a virtualized
LUN hardware path. This hardware path represents the device or LUN itself rather than a single physical path to the device or LUN. For more information, see the intro(7) manpage.
A configuration of disks useful for segregating highly I/O-intensive areas. For example, you might have a database on one channel and file systems on another. When mirroring logical volumes using HP MirrorDisk/UX, you can spread the mirrored copies over different I/O channels to increase system and data availability.
Legacy DSFs are used in releases prior to HP-UX 11i v3, and also supported on HP-UX 11i v3.
A legacy DSF is a DSF with the hardware path information such as SCSI bus, target, and LUN embedded in the file's minor number and file name, such as /dev/dsk/c2t3d4. Because legacy
DSFs are based on physical paths, a single multi-pathed LUN often yields multiple legacy DSFs.
The representation of legacy hardware paths and legacy Device Special Files, as in releases prior to HP-UX 11i v3.
Logical Extents
Logical Volume
Logical Volume
Manager
LUN
Lunpath
Fixed-size addressable areas of space on a logical volume. The basic allocation unit for a logical volume, a logical extent is mapped to a physical extent; thus, if the physical extent size is 4 MB, the logical extent size will also be 4 MB. The size of a logical volume is determined by the number of logical extents configured.
A virtual storage device of flexible size that can hold a file system, raw data, dump area, or swap. Because its data are distributed logically (rather than physically), a single logical volume can be mapped to one LVM disk or span multiple disks. A logical volume appears to the administrator as though it was a single disk.
An operating system software module that implements virtual (logical) disks to extend, mirror, and improve the performance of physical disk access.
LUN represents a virtual disk unit. Most servers store data on external disk arrays. Storage in an array is subdivided into Logical Units (LUNs). The array assigns each LUN a globally unique
WW Identifier (WWID), which is a 64–bit number typically displayed in hexadecimal form.
Array administrators also assign each LUN an easier to remember LUN ID number. HP-UX sees each LUN as a disk device.
A physical hardware path leading to a SCSI logical unit. A SCSI LUN can have more than one lunpath if the LUN can be accessed via different physical hardware paths. Compare this with the single virtualized hardware path to the LUN, called the hardware path. For more information, see the intro(7) manpage.
177
Mirroring
Persistent Device
Special Files (DSFs)
Physical Extents
Physical Volume
Physical Volume
Group
Quorum
Simultaneous replication of data, ensuring a greater degree of data availability. LVM can map identical logical volumes to multiple LVM disks, thus providing the means to recover easily from the loss of one copy (or multiple copies in the case of multi-way mirroring) of data. Mirroring can provide faster access to data for applications using more data reads than writes. Mirroring requires the MirrorDisk/UX product.
A Device Special File conforming to the naming model introduced in HP-UX 11i v3 to support agile addressing. The Device Sepcial File name contains an instance number, such as
/dev/disk/disk#
, and the minor number has no hardware path information. Persistent DSFs provide a persistent, path-independent representation of a device bound to the device's LUN hardware path and World Wid Identifier (WWID). The persistent DSFs represent the LUN itself
(rather than a specific path to a LUN such as legacy DSFs), so a single/persistent DSF is created for a LUN regardless of the number of underlying paths to the LUN.
Fixed-size addressable areas of space on an LVM disk. They are the basic allocation units for a physical volume. Physical extents map to areas on logical volumes called logical extents.
A disk that has been initialized by LVM for inclusion in a volume group; also called an LVM disk.
As with standard disks, an LVM disk (physical volume) is accessed via a raw device file (for example, /dev/rdisk/disk3). Use the HP SMH or the pvcreate command to initialize a disk as a physical volume.
A subset of physical volumes within a volume group, each with a separate I/O channel or interface adapter to achieve higher availability of mirrored data.
The requirement that a certain number of LVM disks be present in order to change or activate a volume group. To activate a volume group, quorum requires the number of available LVM disks to be more than half the number of configured LVM disks that were present when the volume group was last active. To make a configuration change, the quorum requirement is at least half.
If there is no quorum, LVM prevents the operation. Quorum is checked both during configuration changes (for example, when creating a logical volume) and at state changes (for example, if a disk fails). Quorum ensures the consistency and integrity of the volume groups. The vgchange command with the -q n option can be used to override quorum check, but this should be used with caution.
Snapshot Logical
Volume
Striping
A point-in-time image of a logical volume, used to create another copy of the logical volume without taking up as much of the physical space as the size of the logical volume.
Disk striping distributes logically contiguous data blocks (for example, chunks of the same file) across multiple disks, which speeds up I/O throughput for large files when they are read and written sequentially (but not necessarily when access is random).
Synchronization The process of updating stale (non-current) copies of mirrored logical extents by copying data from a fresh (current) copy of the logical volume. Synchronization keeps mirrored logical volumes consistent by ensuring that all copies contain the same data.
Unit of Information The units of information used are as follows:
•
KB is a kilobyte unit of information equal to 2
10 or 1024 bytes.
•
MB is a megabyte unit of information equal to 2
20 or 1,048,576 bytes.
•
GB is a gigabyte unit of information equal to 2
30 or 1,073,741,824 bytes.
•
TB is a terabyte unit of information equal to 2
40 or 1,099,511,627,776 bytes.
•
PB is a petabyte unit of information equal to 2
50 or 1,125,899,906,842,624 bytes.
Unshare Unit
Volume Group
The smallest unit at which data is unshared between a logical volume and its snapshot when a write occurs onto the snapshot or its successor.
A collection of one or more LVM disks from which disk space may be allocated to individual logical volumes. A disk can belong to only one volume group. A volume group is accessed through the group file (for example, /dev/vg01/group) in that volume group's directory. Use
HP SMH or the vgcreate command to create a volume group.
178 Glossary
Index
Symbols
/etc/lvmconf/ directory, 18, 35, 70
/etc/lvmtab, 11, 21, 39, 57, 71, 72, 108, 115, 163,
/var/adm/syslog/syslog.log, 111, 114, 163, 173
A
adding a mirror to a logical volume, 55
adding a physical volume to a volume group, 51
contiguous and noncontiguous, 25
alternate boot disk
alternate links see multipathing
B
backups
volume group configuration, 69
VxFS snapshot file system, 101
bad block relocation, 88, 102, 103, 111
BDRA
requirement for boot disks, 89
Boot Data Reserved Area see BDRA
C
character device file, 13 cluster-wide device special files, 13
contiguous allocation
for dump logical volume, 102 for swap logical volume, 102
converting a physical volume from bootable to
creating a dump logical volume, 102
creating a file system logical volume, 97
creating a mirror of the boot disk, 90
creating a mirrored logical volume, 53
creating a physical volume, 43
creating a striped logical volume, 52
creating a swap logical volume, 102
creating a volume group, 12, 44
creating an alternate boot disk, 88
D
database partitions
device file
creating, 44, 66, 72, 89, 90, 93
logical volume, 14, 15, 52, 56
physical volume, 13, 15, 73, 90, 93, 163
volume group, 15, 44, 57, 66, 72, 89
disabling a path to a physical volume, 87
disk sparing see sparing disk striping see striping
see also physical volumes
displaying LVM information, 40
dual cabling (dual controllers) see multipathing
E
extending a file system logical volume, 98
extending a logical volume, 53
extending a logical volume to a specific disk, 54
extending a swap logical volume, 102
F
file system logical volume, 21
179
boot file system see boot logical volume
determining who is using, 57, 68, 99, 100, 131
performance considerations, 22
root file system see root logical volume
stripe size for HFS, 32 stripe size for VxFS, 32
finding logical volumes using a disk, 123
fuser command, 55, 57, 68, 99, 100, 131
G
H
HP SMH, 9, 38 managing LVM, 38
I
idisk command, 89, 92, 93, 136, 139
insf command, 89, 90, 93, 136, 139
io_redirect_dsf command, 130, 133, 136
ioscan command, 35, 107, 130, 133, 136, 164
to determine device files, 43, 73
to determine hardware paths, 129, 131, 134
to determine instance numbers, 130, 132, 135
K
L
LIF volume
requirement for boot disks, 44, 89
logical extents
180 Index
and rounding logical volume size, 21
mapping to physical extents, 10
Logical Interface Format see LIF volume
see also boot logical volume
see also dump logical volume
see also root logical volume
see also swap logical volume
creating on a specific disk, 54
determining who is using, 55, 57, 68, 99, 100, 131
extending to a specific disk, 54
setting synchronization policy, 25, 90
for dump logical volume, 102 for swap logical volume, 102
setting scheduling policy, 25 setting synchronization policy, 25
lvdisplay command, 10, 26, 35, 40, 42, 107, 108, 152
displaying extent status, 123 displaying mirror status, 123
adding a mirror, 56, 91, 94, 152
extending a logical volume, 53, 152
extending to a specific disk, 54, 88
lvlnboot command, 12, 17, 35, 40, 152
displaying boot information, 16, 89, 92, 94, 107, 123
for boot logical volume, 88, 89
for dump logical volume, 89, 103
for swap logical volume, 89, 102
updating boot information, 36, 92, 94, 115
lvmadm command, 12, 39, 107, 108, 112, 150, 152,
reducing a file system, 100, 115
reducing a logical volume, 55, 152
removing a mirror from a specific disk, 56
M
maintenance mode boot, 90, 115
requirement for boot logical volume, 88
mapping logical to physical extents, 10
merging a split mirror logical volume, 68
Mirror Consistency Recovery, 26
mirror copy
determining if a logical volume is mirrored, 123
handling non-recoverable errors, 110
handling recoverable errors, 109
logical to physical extent mapping, 10
mirroring the boot disk,
physical volume groups, 30, 33
primary swap logical volume, 90
quiescing a logical volume, 66
replacing a non-boot disk, 129
mkboot command, 17, 89, 91, 93, 137
mknod command, 44, 66, 72, 89, 153
modifying a mirrored logical volume, 53
modifying a volume group's parameters, 58
moving physical volumes, 71, 72
removing multipathed disks, 52
setting up, 28 switching between links, 28 using LVM, 28
N
newfs command, 32, 98, 100, 134
NFS
non-strict allocation policy, 24
P
parallel scheduling policy, 25
beyond the size of a physical volume, 84
finding which logical volume is using, 123
moving to another disk, 52, 59, 63
performance considerations, 29
181
physical volume groups, 30, 33
Physical Volume Reserved Area see PVRA physical volumes
converting from bootable to nonbootable, 84, 169
primary swap logical volume, 23 as a dump area, 23
disabling a path, 87, 129, 132, 134, 138
restoring volume group configuration, 70
pvck command, 12, 39, 108, 153 pvcreate command, 9, 12, 39, 43, 153
for boot disks, 44, 89, 91, 93
pvdisplay command, 10, 35, 39, 41, 107, 108, 153
finding logical volumes using a disk, 123
pvlinks see multipathing
abnormal termination, 75 auto re-balancing, 75
moving physical extent 0, 59, 60, 63, 65
PVRA
Q
182 Index
overriding at boot, 91, 93, 112, 135, 138
R
raw data logical volume
reducing the size of a file system logical volume, 99
removing a dump logical volume, 103
removing a mirror copy from a disk, 126
removing a mirror from a logical volume, 56 from a specific disk, 56
removing a physical volume from a volume group, 51
resizing a physical volume, 77
resizing a swap logical volume, 102
restoring data
volume group configuration, 70
resuming a queisced volume group, 65
root volume group
S
scheduling policy, 25 parallel, 25 sequential, 25
scsimgr command
during disk replacement, 130, 132, 135
sequential scheduling policy, 25
snapshot logical volumes
space-efficient, 103 types, 103 space-efficient snapshot, 103
spanning
performance considerations, 30
splitting a mirrored logical volume, 68
creating a striped logical volume, 52
interleaved disks, 31 performance considerations, 31
swap logical volume, 22, 23, 101
see also primary swap logical volume
creating, 89, 102 extending, 102
performance considerations, 22
requirements, 11, 88, 102 resizing, 102
Mirror Consistency Recovery, 26
none, 26 synchronizing a mirror, 26 automatically, 26 manually, 26
System Management Homepage see HP SMH
T
timeout
U
unshare unit
V
Version 1.0 volume groups, 11, 16, 44, 147
Version 2.0 volume groups, 12, 147
Version 2.1 volume groups, 12, 147
Version 2.x volume groups, 12, 16, 22, 23, 27, 40, 44,
45, 76, 77, 84, 88, 90, 101, 102, 108, 112, 167,
vgcdsf command, 39, 153 vgcfgbackup command, 35, 39, 66, 69, 153
vgcfgrestore command, 39, 70, 107, 153
checking if physical volume is bootable, 85
recovering corrupted LVM data, 115
activating a volume group, 58, 61, 66, 71, 72, 73,
attaching all detached links, 88, 131, 133, 137
deactivating a volume group, 57, 61, 66, 67, 71, 72,
disabling quorum checks, 67, 111
enabling quorum checks, 68, 112
quiescing a volume group, 66 resuming a quiesced volume group, 66
vgcreate command, 39, 44, 45, 153
vgdisplay command, 35, 39, 41, 107, 108, 153
displaying free space, 52, 53, 164
vgdsf command, 39, 153 vgexport command, 39, 57, 71, 153
with multipathed disks, 28, 58
vgimport command, 39, 58, 71, 153
183
vgmodify command, 12, 39, 58, 153
changing physical volume type, 84, 169
collecting information, 59, 62
modifying volume group parameters, 59, 171
resizing physical volumes, 77, 165
VGRA
size dependency on extent size, 17, 169
vgremove command, 39, 68, 154 vgscan command, 39, 154
vgsync command, 26, 39, 154 vgversion command, 40, 46, 154
volume group configuration
volume group identifier see VGID
volume group migration to new disks, 95
Volume Group Reserved Area see VGRA
Version 2.x, 12, 16, 22, 23, 27, 40, 44, 45, 76, 77,
84, 88, 90, 101, 102, 108, 112, 167, 169
volume groups
device file, 15, 44, 57, 66, 72, 89
importing, 58 modifying parameters, 58
performance considerations, 30
VxFS snapshot file system, 101
184 Index
Shkarko
Lidhja publike u përditësua
Lidhja publike për bisedën tuaj është përditësuar. You may view and manage your chat links after registration here.
Lidhja publike e dokumentit
Reklamë
