Posts tagged ·

lvm

·...

How to setup LVM hot spare

Comments Off

Question

Setup LVM hot spare.

Answer

Hot Spare only works if the volume group has mirrored logical volumes. There can be no logical partitions using the drive to be marked a hot spare. The following command marks hdisk1 as a hot spare disk:

# chpv -hy hdisk1

Now that the drive is marked as a hot spare you must determine the hotsparepolicy, and the syncpolicy. Here are your options:

Hotsparepolicy:

y This policy automatically migrates partitions from one failing disk to one
spare disk. From the pool of hot spare disks, the smallest one that is big
enough to substitute for the failing disk will be used.

Y This policy automatically migrates partitions from a failing disk, but might
use the complete pool of hot spare disks.

n No automatic migration will take place. This is the default value for a volume group.

r This value removes all disks from the pool of hot spare disks for this volume group.

Syncpolicy:

y This will automatically try to synchronize stale partitions.

n This will not automatically try to synchronize stale partitions. The latter argument is also the default for a volume group.

This is the syntax to set the policies:

# chvg -h hotsparepolicy -s syncpolicy VolumeGroup

for example:

# chvg -hy -sy vgname

Now the vg will have a hot spare.

Comments Off

Do Not Mix Oracle ASM Disks With LVM

Comments Off
Question
This technote discusses Oracle ASM and LVM disks
Answer
In Oracle 10g Oracle released a disk management layer named Automatic Storage Management (ASM). This is typically deployed with Oracle RAC in order to manage raw disks used by the Oracle database in a RAC cluster.Disks being used by Oracle ASM cannot be also used with AIX LVM. The main reason for this is because the Oracle ASM software puts information on the raw disk to identify it as an Oracle disk, which wipes out any existing PVID or VGDA information.

 

If an attempt is made to use LVM on a disk already in an Oracle ASM disk group the following errors will be seen:
root> extendvg -f apps hdiskpower7
0516-1339 extendvg: Physical volume contains some 3rd party volume group.
0516-1397 extendvg: The physical volume hdiskpower7, will not be added to the volume group.
0516-792 extendvg: Unable to extend volume group.

root> mkvg -y testvg hdiskpower7
0516-1339 mkvg: Physical volume contains some 3rd party volume group.
0516-1397 mkvg: The physical volume hdiskpower7, will not be added to the volume group.
0516-862 mkvg: Unable to create volume group.

Here is the debug output from the alog LVMT debug:

[S 1507490 1531914 07/10/09-07:48:58:138 mkvg.c 412] extendvg apps hdiskpower7
[2 1507490 0:024 mkvg.c 1662] validate_pvs: Found an Oracle disk(hdiskpower7)
[2 1507490 0:024 mkvg.c 1668] validate_pvs: Disk(hdiskpower7) is in use by Oracle or f flag not used [1 1507490 0:024 mkvg.c 1870] validate_pvs: FAIL: Invalid PVs! num_invalid_pvs rc=1
[1 1507490 0:024 mkvg.c 686] main: FAIL: validate_pvs failed
[1 1507490 0:024 mkvg.c 167] cleanup_exit: FAIL: pv_failures=1
[E 1507490 0:292 mkvg.c 268] extendvg: exited with rc=1

LVM knows to search for the Oracle identifier on these disks, and will fail the operation. You can manually check for the identifier by running the lquerypv command.
# lquerypv -h /dev/hdiskpower7
00000000 00820101 00000000 80000000 F7BE76D7 |…………..v.|
00000010 00000000 00000000 00000000 00000000 |…………….|
00000020 4F52434C 4449534B 00000000 00000000 |ORCLDISK……..|
00000030 00000000 00000000 00000000 00000000 |…………….|
00000040 0A100000 00000103 44415441 5F303030 |……..DATA_000|
00000050 30000000 00000000 00000000 00000000 |0……………|
00000060 00000000 00000000 44415441 00000000 |……..DATA….|
00000070 00000000 00000000 00000000 00000000 |…………….|
00000080 00000000 00000000 44415441 5F303030 |……..DATA_000|
00000090 30000000 00000000 00000000 00000000 |0……………|
000000A0 00000000 00000000 00000000 00000000 |…………….|
000000B0 00000000 00000000 00000000 00000000 |…………….|
000000C0 00000000 00000000 01F64610 3B306C00 |……….F.;0l.|
000000D0 01F64610 3B9C7C00 02001000 00100000 |..F.;.|………|
000000E0 0001BC80 0000C800 00000002 00000001 |…………….|
000000F0 00000002 00000002 00000000 00000000 |…………….|

There are 3 data points to note in the lquerypv output:

1. The presence of the Oracle ASM identifier “ORCLDISK”.

2. The lack of a PVID on location 80.

3. The lack of the AIX disk identifier “C9C2D4C1″ in location 00.

Comments Off

AIX LVM QUORUM mysteries revealed

Comments Off

 Technote (FAQ)
 
Question
Why can't I varyon a Volume Group when one or more physical volumes are not available?
 
Cause
Varyonvg requires 100% of it's physical volumes be available and accessible in order to successfully vary on the Volume Group without using the force option.
 
Answer
A common misconception is that the QUORUM setting of an LVM Volume Group can affect one's ability to varyon a volume group, when, in fact, the Volume Group QUORUM setting (enabled or disabled) has no bearing on the varyon process. This misconception is further enhanced by the following varyonvg error message...
0516-052 varyonvg: Volume group cannot be varied on without a
       quorum. More physical volumes in the group must be active.


This message indicates a "quorum" of physical volumes must exist in order to varyon the Volume Group and is unrelated to the Volume Group's QUORUM setting.

The Volume Group QUORUM setting is a concept that applies only to currently varied on Volume Groups in order to force varyoff of the Volume Group should it lose more than 51% of it's disks. With QUORUM disabled on the Volume Group, loss of one or more disks will not cause the Volume Group to varyoff. If QUORUM is enabled on the Volume Group, LVM will force varyoff the Volume Group if less than 51% of it's disks are available and accessible. For a two disk Volume Group with QUORUM enabled, LVM will check the number of VGDAs on each disk and varyoff the Volume Group should it lose QUORUM (if it loses the disk with two active VGDA's).

The Volume Group's QUORUM setting has no meaning for a Volume Group which is currently varied off. Varyonvg does not look at how many VGDAs a disk has, it ONLY looks at the number of physical volumes which are available and accessible. Without the -f (force) flag, ALL physical volumes in a Volume Group must be available and accessible. If one or more physical volumes is unavailable, the Volume Group may be forced online with varyonvg -f.


Excerpts from the varyonvg man page...

"The varyonvg will fail to varyon the volume group if a majority of the physical volumes are not accessible (no Quorum). This condition is true even if the quorum checking is disabled. Disabling the quorum checking will only ensure that the volume group stays varied on even in the case of loss of quorum."

"If the volume group cannot be varied on due to a loss of the majority of physical volumes, a list of all physical volumes with their status is displayed. To varyon the volume group in this situation, you will need to use the force option."

"-f Allows a volume group to be made active that does not currently have a quorum of available disks. All disk that cannot be brought to an active state will be put in a removed state. At least one disk must be available for use in the volume group."
 
 
Cross Reference information
Segment Product Component Platform Version Edition
Operating SystemsAIX family AIX5.2, 5.3, 6.1
 
 
Comments Off