 |
» |
|
|
 |
|  |  |
Logical Volume Manager (LVM) is the HP-UX default Volume Manager.
It provides the user with flexibility in configuring and managing
mass storage resources. In HP-UX 11i v3, the LVM kernel and commands
are bundled with the core HP-UX product. MirrorDisk/UX (B2491BA)
is an optionally purchased HP-UX product to enable LVM mirroring
functionality. Summary
of Change |  |
What’s
New for Customers Migrating from HP-UX 11i v2 June 2006? In HP-UX 11i v3, LVM delivers significant performance, scalability
and availability enhancements. It supports the next generation mass
storage stack, described under Mass Storage Stack (“Mass Storage Stack”) and is integrated with the
mass storage stack’s load balancing and dynamic LUN expansion
features. LVM also supports Error Management Technology (EMT). In addition, LVM has been enhanced to support larger logical
volumes, striping with mirroring of logical volumes, temporary quiescing
of volume groups, and dynamic LUN expansion. LVM also provides a
new vgmodify command, which enables modification of a volume group
parameters. Increased logical volume size: LVM
now supports logical volumes up to 16 terabytes (16TB) in size,
an increase from 2TB in previous releases. Logical volumes larger than
2TB may not be usable on previous releases; see the compatibility
note below. The tunable parameter maxvgs has been obsoleted; LVM can now create up to 256 volume
groups dynamically. LVM Device Online Replacement (OLR): The pvchange command has a new option, -a, that can
be used to temporarily stop LVM accessing a device or device special
file, and to reenable access. A white paper (see “Documentation” below) explains how OLR simplifies
the process of replacing or isolating disks. (This feature was introduced
in HP-UX 11i Version 2 June 2006.) Volume Group Quiesce/Resume: Two new options, -Q and -R,
have been added to the vgchange command. These options temporarily quiesce an activated
volume group and resume it, respectively, and are discussed in detail
on the vgchange(1M) manpage. Using the -Q option, you can quiesce both
read and write operations to the volume group, or just write operations.
While the volume group is quiesced, the vgdisplay command will report the volume group’s status
as “quiesced.” The indicated I/O operations will be
queued until the volume group is resumed, and commands that would
modify the volume group configuration will return an error. This
keeps the volume group disk image in a stable state suitable for
using disk management utilities to perform snapshots of all the
disks in the volume group, without deactivating the volume group. Note that the entire volume group is quiesced. Individual
logical volumes or physical volumes cannot be quiesced using this
feature. To disable or replace a physical volume or PVLink, use
the pvchange command. To provide a stable image of a particular logical
volume, in order to back up the data there, use the lvsplit command. Striping with Mirroring: In previous releases, LVM
supported a limited extent-based striped mirror functionality, as
described in the lvcreate(1M) manpage. This type of striped
mirror required the stripe size to be a multiple of extent size.
In HP-UX 11i v3, LVM supports mirroring of striped logical volumes
with the entire range of stripe sizes. The lvcreate command options -m and -i/-I can
be used together, and the -m option of the lvextend and lvreduce commands can be applied to striped logical volumes.
Note that logical volumes configured with such striped mirrors cannot
be imported on releases before HP-UX 11i v3; see the compatibility
note below. To maximize data Integrity for striped mirrors, LVM enforces
a strict allocation policy; that is, mirrored physical extents must
be allocated on different physical volumes. This forces the physical
extents used by all the replicas of a strip onto different physical
volumes. Mass Storage Stack: LVM supports the next generation
mass storage stack, as described in the Mass Storage Stack section
of this document. In particular, LVM supports the use of both legacy
and persistent device special files within the same volume group.
New options to the vgscan and vgimport commands, described below, affect how LVM creates its
configuration. By default, vgscan recovers the LVM configuration information (the /etc/lvmtab file) using legacy device special files. If the new -N option
is specified, then vgscan will use persistent device special files. If the new -B option
is specified, then vgscan will populate the /etc/lvmtab file using both legacy and persistent device special files. By default, when importing a volume group in shared mode, vgimport will populate the /etc/lvmtab file using legacy device special files. If the new -N option
is specified, then vgimport will use persistent device special files. Multi-pathing and Alternate Links (PVLinks): Management
of multi-pathed devices is available outside of LVM using the next
generation mass storage stack. By default, the mass storage stack
balances the I/O load across all available paths to a disk. However,
the new scsimgr command can be used to emulate LVM’s PVLink functionality,
and offers additional options for handling LUN failure and load balancing. HP recommends converting volume groups with multi-pathed disks
to persistent device special files. This can be done by running
the /usr/contrib/bin/vgdsf, vgscan -N, or vgimport -s -N commands. SLVM Single Node Online Volume Reconfiguration (SNOR):
A new option, -x, has been added to the vgchange
command. This option allows an administrator to make configuration
changes to a shared volume group while keeping the volume group activated
on one cluster node. A white paper, described below, explains the
SNOR functionality. Dynamic Volume Group Modification: A new command, vgmodify, is available to dynamically modify a volume group’s
characteristics. In previous releases, the number of physical volumes,
the number of logical volumes, and number of physical extents per
disk were set when a volume group was created; the vgmodify command allows these parameters to be modified without
recreating the volume group. Dynamic LUN Expansion: If the administrator increases
the size of a LUN, the vgmodify command can be used to incorporate that additional space
into the volume group without recreating the volume group. Boot resiliency: If during boot time the LVM subsystem
detects an inconsistency between the firmware boot path and the
LVM root volume group configuration, LVM will scan all the disk
devices to find the physical volumes belonging to the root volume
group and will continue the boot sequence. In previous releases,
the administrator had to boot in LVM Maintenance Mode to resolve
this inconsistency. Display enhancements: The lvdisplay, pvdisplay, vgdisplay, and vgscan commands all support the long hostnames described in “Long hostname, uname,
and setuname”. Those commands
also support a new -F option to print in a format
more easily parsed by user scripts. The pvdisplay command has a
new -l option to display if a disk is under LVM
control; the existing -d option displays if a physical
volume is a bootable physical volume. vgscan enhancements: In addition to support of the mass storage
stack, vgscan has new -f and -k options. By default, the vgscan command does not modify or supplement the /etc/lvmtab file entries for volume groups that already have entries.
The new -f option forces an update of the existing
entries for the specified volume group. By default, the vgscan command scans the I/O configuration searching for LVM physical
volumes, which can be a time-consuming operation. The new -k option reads
the LVM data structures in kernel memory and populates the /etc/lvmtab file based on that data.
Impact |  |
The new LVM features enable increased availability and adaptability
of mass storage: LVM Device
OLR functionality provides users with the flexibility to adjust
their storage hardware without disabling LVM. Volume group quiescence allows
users to snapshot a consistent LVM configuration without deactivating
the volume group. Striping with mirroring adds
flexibility in mass storage configuration. Integration with the next
generation mass storage stack allows the use of its features, such
as enhanced multi-pathing and load balancing. LVM SNOR functionality allows
users to keep their applications running on a single node while
modifying the underlying volume groups. Dynamic LUN expansion and
Dynamic Volume Group Modification give users the ability to grow
and modify their storage without recreating a volume group.
Compatibility |  |
Releases prior to HP-UX 11i v3 can only access data within
the first 2TB of a logical volume. If a logical volume larger than
2TB is created on HP-UX 11i v3, its activation and use are not recommended
on any previous HP-UX release. The logical volume can be activated
and used, but the data beyond 2TB will be inaccessible. Releases prior to HP-UX 11i v3 only support extent-based striping
via the -D option to lvcreate. If a logical volume
using simultaneous mirroring and non-extent-based striping is created
on HP-UX 11i v3, attempts to import or activate its associated volume
group will fail on a previous HP-UX release. To import the volume
group, you must remove the incompatible logical volumes or reduce
them to a single mirror. There is no longer a requirement to use the lvlnboot command
to configure swap and dump logical volumes. Instead, the swapon
and crashconf commands should used to configure those logical volumes;
if these commands are used, the lvlnboot command will not display
information about the swap and dump logical volumes. In addition,
lvlnboot no longer displays hardware paths, but device special files. After a volume group containing a logical volume using the
Mirror Write Cache is activated on HP-UX 11i v3, its Mirror Write
Cache format will be converted. Any subsequent activation on previous
releases will not recognize the new MWC format and a full resync
will happen. Note that this would happen during a Serviceguard rolling update
configuration. By default, the next generation mass storage stack distributes
I/O requests across all available paths to a multi-pathed disk,
even when using legacy device special files. Using LVM with persistent
or legacy device special files may cause I/O requests to be sent across
alternate links, even if the links are not configured as PVLinks.
To force backward-compatible multi-pathing behavior on legacy device
special files, use the scsimgr command to configure a global device
tunable called leg_mpath_enable. However, HP recommends converting
volume groups with multi-pathed disks to persistent device special
files and native multi-pathing. Performance |  |
The LVM performance has been improved compared to previous
releases: The
Mirror Write Cache is larger which improves mirrored logical volume performance
by allowing more concurrent writes. See compatibility note above. LVM supports larger I/O sizes
(up to the extent size).
Documentation |  |
For more information about LVM, see HP-UX
System Administration: Logical Volume Management, available
at http://docs.hp.com. For information about migrating an LVM configuration
from legacy device special files and pvlinks to persistent device
special files and native multi-pathing, see the white paper entitled LVM
Migration from Legacy to Agile Naming Model, available at http://docs.hp.com. The LVM Device Online Replacement feature is described
in a white paper entitled LVM Online Disk Replacement
(LVM OLR), available at http://docs.hp.com/en/7161/LVM_OLR_whitepaper.pdf. It includes a description of the new functionality
and procedures for isolating and replacing disk devices. The SLVM Single Node Online Volume Reconfiguration
feature is described in a white paper entitled SLVM Online
Volume Reconfiguration, available at http://docs.hp.com/en/7389/LVM_SNOR_whitepaper.pdf. It includes a description of the new functionality
and procedures for making changes to shared volume groups. In addition, there are over thirty existing manpages
for LVM and its commands. The lvm(7) manpage provides an overview
and list of commands.
Obsolescence |  |
LVM no longer
performs software bad block relocation, as modern disks and disk arrays
handle such relocation in their own hardware. Existing software
relocation information will be honored, unless the physical volume
is larger than 256GB. The tunable parameter
maxvgs is obsolete. Any attempts to modify maxvgs using
the kctune command cause the following error message: ERROR:
There is no tunable named 'maxvgs'.
|