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 quorum 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, 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”.

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:

# 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 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.